Wiktionary:Grease pit/2023/September

Hi @Erutuon: Could you please add alt params for Iranian Persian, the same way you did for Dari and Tajik?

The entry at اِمْپِراطور (emperâtur) could use the alt form (comma-separated) اِمْپِراتور (emperâtur).

FYI: @Sameerhameedy Anatoli T. ^{(обсудить}/^вклад) 04:03, 1 September 2023 (UTC)

@Atitarev @Erutuon Hi, I added the parameter |ir2= to fa-regional. So it should work now. سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 02:57, 19 September 2023 (UTC)

@Sameerhameedy, @Erutuon: Thank you, applied! Anatoli T. ^{(обсудить}/^вклад) 03:05, 19 September 2023 (UTC)

@JWBTH This is a more powerful version of {{temp demo}}, which avoids most of the issues related to that template by requiring that the supplied Wikicode be wrapped in <nowiki>...</nowiki>. It is ported from w:Module:Demo, which I've cleaned up to use Module:parameters and generally avoid some of the nastiness of the original code (surprisingly, Wikipedia module code is generally of lower quality than Wiktionary module code despite the greater number of editors). See the documentation for some examples. Benwing2 (talk) 06:32, 1 September 2023 (UTC)

Discussion moved to Wiktionary:Tea_room/2023/September#"Concussion"_term_in_meteorology%2C_seismology%2C_and_volcanology.

Is it possible to link to Unsupported titles/=) from within a synonym template? I want to add it to the synonyms list on the Unsupported titles/:) page but every way that I tried to get it in produced a Lua error (backslash, typing out "Unsupported titles", etc). Thanks, —Soap— 13:52, 1 September 2023 (UTC)

Well =) also exists, separately, without the "Unsupported titles" prefix (I guess it's not an unsupported title?). You can link there with =). —Al-Muqanna المقنع (talk) 15:28, 1 September 2023 (UTC)

Apologies for not checking. I'd simply assumed a title could not contain an equals sign, let alone begin with one. I will nominate the page I created for speedy deletion since it is both unnecessary and confusing (the title makes it look like the person is at the regular =) page.)

However, the trick you showed me for how to paste the link does not work inside a template, so my question remains ... is it possible to make a link to =) from within a template, particularly the synonym template used on Unsupported titles/:)? Thanks, —Soap— 16:19, 1 September 2023 (UTC)

Never mind, I see it now. I was pasting the code literally from within the edit window and you meant for me to paste it from the live page view. Again, thanks. This should be resolved now. —Soap— 16:21, 1 September 2023 (UTC)

The em space ( ) is displayed incorrectly inside certain templates (such as {{ux}}), see e.g. hard senses 2.1 and 2.3. Einstein2 (talk) 18:14, 1 September 2023 (UTC)

@Theknightwho This is being caused by some weird processing done in embedded_language_links() in Module:links. Benwing2 (talk) 03:28, 2 September 2023 (UTC)

@Benwing2 @Einstein2 It was a bug in get_entities in Module:utilities, which I changed yesterday to reduce the size of the data by removing the & and ; from all the listed entities. For some reason, emsp13 was listed before emsp, so it was wrongly picking up 13 followed by a 1/3 em-space ( ) when it tried to match emsp. I've fixed this individual issue, but I'll go over the data today to make sure shortner names are always listed before longer ones. Theknightwho (talk) 13:07, 2 September 2023 (UTC)

I've resorted the data so that shorter names always come before longer ones, which should prevent any issues like this happening in future. Theknightwho (talk) 13:46, 2 September 2023 (UTC)

Wrong Order: diff Xiaoping Deng; Haishenwai Zedong Mao --Geographyinitiative (talk) 21:00, 1 September 2023 (UTC)

@Geographyinitiative ?? This is a very cryptic post. This, that and the other (talk) 00:10, 2 September 2023 (UTC)

Pardon me! Two citations on these two pages have the names of two prominent figures written with surname last when English Wikipedia's article titles for those two personage are written with surname first. This is not the only two instances of this problem. I have notified @Benwing2, This, that and the other- see diff. I will start adding additional examples of wrong placement of surname after given name here as I see them- here's one: diff (Binyan Liu for Liu Binyan), diff (Li-shih Lu for Lu Li-shih- and the Chinese characters included from the article are deleted), diff diff (Yu-ti Jen for Jen Yu-ti), Muling (Il-sung Kim for Kim Il-sung), diff (Aizhu Chen for Chen Aizhu), diff (Tê-kʻun Chêng for Chêng Tê-kʻun), diff (Zongxu Zou for Zou Zongxu). The problem is so bad and so pervasive, I don't think it can ever be fully corrected, even if I worked on it manually for years. It is to take East Asian Names and make a joke of them. You want to talk about systemic, unintentional racism- well there you go! I'm trying my hardest to be polite here, but this is going to be a black mark on Wiktionary for years, so it's really painful for me because the burden is going to fall on me to correct something that shouldn't have to be corrected. All because what? And in the mean time, while Wiktionary is being copied by other sites and leaving a bad impression on potential readers and editors, Wiktionary's editor core does not care. "烏煙瘴氣. This site will always be a kludge. Let it 自生自滅." Wyang If I came on a website and saw "Zedong Mao" or "Xiaoping Deng", I'm telling you, I wouldn't see it as reliable. I would leave the website. --Geographyinitiative (talk) 08:03, 2 September 2023 (UTC) (Modified)

Might be missing something but didn't you add both of the ones in the original section title (at Muling and Haishenwai)? Is this a case of deliberately bad edits to make a point? I see from your other diffs that Benwing's bot has been rearranging |last= and |first= into |author=first last, but that did not introduce the error since they were incorrectly entered originally: the citation name format "Y, X" means "X Y", hence Wikipedia's CS1 guideline to enter surname-first names purely in the |last= param. —Al-Muqanna المقنع (talk) 10:23, 2 September 2023 (UTC)

@Al-Muqanna Thank you for your reply. I know I may be a silly person, but this is a major, major defect and problem. Like huge. To answer your question: "Deng" is considered a "last name" even though it does not come "last". "last name" means "surname". That's the way East Asian Names work (most of the time, unless the author has Westernized). It's a simple cultural difference. --Geographyinitiative (talk) 10:27, 2 September 2023 (UTC)

I am well aware of how East Asian names work—Hungarian names are also natively surname-first, incidentally: I'm talking about how to enter them in a citation. —Al-Muqanna المقنع (talk) 10:28, 2 September 2023 (UTC)

@Al-Muqanna "Deng, Xiaoping" is correct. "Deng Xiaoping" is correct. "Xiaoping Deng" is an abomination (unless the author specifically uses it that way). It ruins all cites that are written with it, or if not "ruins" we can say "culturally whitewashes". Let me know if that's not answering the question. --Geographyinitiative (talk) 10:31, 2 September 2023 (UTC)

My point is precisely that "Deng, Xiaoping" is not correct since it means "Xiaoping Deng". So for example Wikipedia's Template:Cite book states, "Where the surname is usually written first—as in Chinese—or for corporate authors, simply use editor-last to include the same format as the source". They were entered incorrectly, and will need to be corrected now either way. —Al-Muqanna المقنع (talk) 10:35, 2 September 2023 (UTC)

@Al-Muqanna "Oh there's some special parameter on Wikipedia bro, lol". That doesn't solve the problem. The surnames were in the correct order when viewed by a reader looking at the entry page (not the code itself), and now they are not. Do you contest this? Do you not think this new order hurts the reliability or trustworthiness of the cites in the eyes of readers? I am done with this conversation. Thanks for your time. --Geographyinitiative (talk) 10:39, 2 September 2023 (UTC)

@Geographyinitiative: Yes, because, like I said, "Y, X" means "X Y", not "Y X". They were incorrect originally and are still incorrect. More directly: you entered them incorrectly and are now trying to fob off the responsibility on Benwing. It has absolutely nothing to do with special parameters on Wikipedia or whatever, the Wikipedia guidelines are indications of how to produce the correct result on Wikipedia; in our case we don't need to use "last"-type parameters at all since we simply have |editors= etc. —Al-Muqanna المقنع (talk) 10:44, 2 September 2023 (UTC)

Oh wow, well I never realized that I was wrong, but now I see that I was actually making an error. I totally get this now. It was me that was doing the systemtic, unintentional racism the whole time. I have attempted to apologize to Benwing here: diff. I just had a mistaken understanding of how Y, X and XY worked, but now I see that the comma actually means that it's X Y. I really did not know that before. How I never realized this, I will never know- just not well educated or such. I apologize for any confusion, but my misunderstanding led me to make this mistake for years, and then when I see this problem everywhere now, I was like "uhh wtf this is bad". I will try to correct the issue manually over time. I really appreciate you laying this out for me- it's so basic and simple, but I literally just did not know I was doing it wrong. Sincerely, Thanks! --Geographyinitiative (talk) 10:54, 2 September 2023 (UTC)

@Al-Muqanna's interpretation of |last= and |first= is newly promulgated. I warned at the time that it would cause trouble, that there was the interpretation of 'last' and 'first' as surname and personal name. --RichardW57m (talk) 15:13, 5 September 2023 (UTC)

I was messing with the Wikitionary {{head}} and ended with some ideas for Old Tupi headwork templates. What do you think? @RodRabelo7 @Bageense

For nouns:

• User:Trooper57/Template:tpw-noun - just tells if the noun is possessable or not; couldn't think of many things to add since there's no number nor gender
• User:Trooper57/Template:tpw-pluri noun - for pluriform nouns; maybe merge it with the first
• User:Trooper57/Sandbox4 - some usage examples

Trooper57 (talk) 05:06, 2 September 2023 (UTC)

@Trooper57 I don't use Wiktionary often, so I can't tell whether your templates are good, or whether they were made according to some standard. In any case, it's nice to see another wikipedian who studies the Tupi language! See you around. Bageense (talk) 14:14, 2 September 2023 (UTC)

@Benwing @Theknightwho (Since you've updated Module:affix/templates lately) This request was already raised here, but we should have an equivalent to {{PIE root see}} as {{PII root see}}, {{PIA root see}}, and {{sa root see}}. Right now the module is locked, but this should be easy enough to implement and I could suggest or write the Lua for it if I had permissions. Dragonoid76 (talk) 10:13, 2 September 2023 (UTC)

@Dragonoid76 I don't think we need a bunch of lang-specific templates like this; we need one general template that takes a language code. In fact we have {{derivsee}} for this purpose already. IMO {{PIE root see}} should be removed and replaced with calls to {{derivsee}}. Benwing2 (talk) 13:27, 2 September 2023 (UTC)

@Benwing2 how would one call {{derivsee}} to see, for instance, Category:Terms derived from the Sanskrit root भृ

Could you add this to the documentation of {{derivsee}} if this is the intended way of using it. Dragonoid76 (talk) 19:17, 2 September 2023 (UTC)

Something seems to be broken with columns on category pages. See WT:RTINE which is displaying as a single column. -- Sokkjō 10:23, 3 September 2023 (UTC)

Hmm... CAT:English lemmas is still two columns as expected, and I know categories with fewer than some number of entries never get split into columns, e.g. Category:English postpositions is one column and was in 2021, and RTINE was also one column already back in 2021. (I see that it was two columns back in 2015, when it had fewer entries than in does now, but perhaps the threshold for when to split off a second column was raised between 2015 and 2021.) Or did it still have two columns recently for you? Perhaps the length of the entries' names and the width of one's screen cause different numbers of columns to be displayed on different devices? - -sche (discuss) 17:29, 3 September 2023 (UTC)

@-sche: It's very resent but it sems to have been fixed now. 🤷 -- Sokkjō 18:32, 3 September 2023 (UTC)

Mysterious! RTINE is still showing up as one column for me (even if I null-edit some of the templates and then the category page itself). - -sche (discuss) 18:40, 3 September 2023 (UTC)

@-sche: Caching, I guess. -- Sokkjō 20:06, 3 September 2023 (UTC)

@-sche Going through Category:Templates by language, I notice that the single-column format is more common at lower levels in the tree. It might be something as simple as having subcategories on the same page as the categories. Chuck Entz (talk) 22:19, 3 September 2023 (UTC)

@-sche, Chuck Entz Votes are weirdly placed on my watchlist page now too. I'm thinking this is related to @This, that and the other's edits to Common.css. @Surjection, Benwing -- Sokkjō 00:08, 4 September 2023 (UTC)

This is presumably to do with the width of the box titled "Newest pages ordered by last category link update" reducing the available space for columns. I made an experimental edit to this category page; can you check it now, @Sokkjo? If that solves the problem we would need to look at incorporating {{-}} into the output of {{auto cat}} on category pages with that wide box.

The weird placement of the watchlist vote box can be resolved by a similar fix. It's possible that my edits to Common.css broke this, but I did check carefully where the class names were in use across all namespaces. This, that and the other (talk) 02:20, 4 September 2023 (UTC)

I just checked; the watchlist votes box is difficult to move. What exactly has changed in the way it looks for you, @Sokkjo? This, that and the other (talk) 02:23, 4 September 2023 (UTC)

@-sche, is WT:RTINE still a single column for you? @This, that and the other, the votes box is being moved to the left of the "Edit your list of watched pages", but maybe it's been that way for while? -- Sokkjō 02:58, 4 September 2023 (UTC)

Adding {{-}} has caused RTINE to be two columns for me. - -sche (discuss) 19:54, 4 September 2023 (UTC)

I think the solution here is to incorporate the functionality of {{-}} into {{auto cat}} and make the "Newest pages ordered by last category link update" box collapsible, collapsed by default:

Newest and oldest pages
contents go here!

This, that and the other (talk) 12:18, 6 September 2023 (UTC)

@This, that and the other: I wouldn't be opposed to collapsing that, but I also think column-width: 24em in .mw-category.mw-category-columns is too wide. Maybe column-width: 16em with column-gap: 2em; -moz-column-gap: 2em; -webkit-column-gap: 2em. -- Sokkjō 18:10, 6 September 2023 (UTC)

Hopefully  fixed on all category pages now. This, that and the other (talk) 00:41, 27 September 2023 (UTC)

Ideally, I would like this template, as currently used on pages such as plash and splurt, to link to Appendix:Glossary#imitative when imitative is the word we display. Currently it just displays an unclickable plaintext word. If that is not possible or not convenient, I would still think it an improvement if the template always linked to Appendix:Glossary#onomatopoeic rather than linking to that only when the title= param is omitted. Both the template and the module it invokes are protected so I can't edit them (and likely wouldn't know what to do, anyway). Please help. Best regards, —Soap— 13:18, 3 September 2023 (UTC)

A comment: Dutch plas currently uses the display word imitation instead of imitative, and there are probably others like this ... this could also link to the "imitative" glossary entry if possible, but otherwise I still think a link to #onomatopoeic is better than an unclickable word. —Soap— 13:20, 3 September 2023 (UTC)

Also it seems that any of use of the title= argument breaks the link, even if the title given is onomatopoeic. —Soap— 08:54, 5 September 2023 (UTC)

Would it be possible to add a parameter that prints the text "Rhyming phrase" to the beginning of lit, decapitalizes "literally", and adds the page to the appropriate language's category "rhyming phrases"? Vininn126 (talk) 14:30, 3 September 2023 (UTC)

Huh? No. Chuck Entz (talk) 14:49, 3 September 2023 (UTC)

Why not? Vininn126 (talk) 15:21, 3 September 2023 (UTC)

Why not just a separate template for rhyming phrases? —Al-Muqanna المقنع (talk) 14:57, 3 September 2023 (UTC)

I suppose. My reasoning for this is that rhyming phrases will necessarily always be with... well multiword terms, which frequently have {{lit}}, so having a parameter would reduce keystrokes. Vininn126 (talk) 15:28, 3 September 2023 (UTC)

But it's also a specific case that doesn't interact with what {{lit}} does by itself and is irrelevant for most of its invocations, so it'd be weird from a code perspective to bolt on that functionality here instead of just building a separate template with a |lit= param (which {{lit}}'s own documentation recommends as a preferred alternative). —Al-Muqanna المقنع (talk) 16:19, 3 September 2023 (UTC)

That's an interesting solution, to be honest. I also appreciate the explanation as opposed to the dismissal Chuck gave... Vininn126 (talk) 16:21, 3 September 2023 (UTC)

At the old version of Tarren, there was some bullshit code producing crap. Any other occurrences of this??? Jin and Tonik (talk) 16:32, 3 September 2023 (UTC)

Seems like bullshit user input and not bullshit code. —Al-Muqanna المقنع (talk) 16:47, 3 September 2023 (UTC)

I have repeatedly had the experience of looking for a list coordinate terms to add another term, in an entry where I knew I'd previously added such a list, but I can't find it even when Ctrl+F-ing terms I know I entered ... and only upon clicking "edit" to (re)add coordinate terms to the entry do I (if the entry is short) notice {{cot}} is present, just hidden with an evidently-easily-missed toggle. I can also use the toggle in the sidebar to opt-in to seeing them in general for the duration of one login from one browser, but I posit that if even I — a user familiar with Wiktionary and our toggles and who is specifically looking for this info which I know exists — miss the existence of the hidden list and its tiny toggle, the odds of lay readers who don't even know it's present figuring out to toggle it into existence (either on a specific entry, or through the main "show semantic relations" toggle tucked away in the sidebar) seem very low, meaning that in practice, we may as well not include the info. I sometimes move terms back to ====Coordinate terms==== sections even though I prefer them being next to the relevant sense using {{cot}}, because ====Coordinate terms==== is visible to readers whereas {{cot}} isn't.
I suggest we make semantic relations visible to users by default, and make hiding them the opt-in behaviour people can choose, rather than having them hidden by default and having seeing them or knowing they exist as the opt-in option that only proficient users know to look for. - -sche (discuss) 18:08, 3 September 2023 (UTC)

Yes, I strongly agree with this. The one I really, really don't understand is {{alti}} (in-line alt forms) being hidden by default as well, which actively makes me not use it. There's no reason why synonyms should be shown by default but alt forms should not. Theknightwho (talk) 18:30, 3 September 2023 (UTC)

I strongly agree as well. I don’t think any semantic relation should be hidden. (I also didn’t even know that {{alti}} existed either) AG202 (talk) 18:33, 3 September 2023 (UTC)

Support making all semantic relations visible by default. —Al-Muqanna المقنع (talk) 00:13, 4 September 2023 (UTC)

Why is this being discussed in GP rather than BP?

If this has to do with defaults, the important thing would be the effect of hiding or not hiding on unregistered users and newbies, others having the ability and knowledge to use the sidebar toggles. I haven't seen the benefits or costs of this expressed in terms of such users. If our main need is to attract and keep users who happen upon Wiktionary, it would be good to imagine what the effect would be of, say, three additional lines (out of syns, ants, hypos, hypers, coords, which are just the top 5) between each pair of consecutive definitions. DCDuring (talk) 00:39, 4 September 2023 (UTC)

I don't think these are anywhere near as common as that, to be fair; it certainly won't be 3 new lines per definition. In general, though, -sche already laid out their proposal specifically in terms of lay users, and to my mind it's unambiguously better not to hide information from users by default. I've also found that when these lines are present in larger entries they actually help to break up long lists of senses. So I don't see the benefits of the current practice from an ordinary-user perspective as outweighing the costs at all. —Al-Muqanna المقنع (talk) 00:48, 4 September 2023 (UTC)

Our goal is to have as many of these as possible. The situation will be different in 3 or 10 years. DCDuring (talk) 16:36, 4 September 2023 (UTC)

I'd prefer to keep hypernyms and hyponyms hidden, but syn/ant/cot should be visible by default for sure. I'd even suggest to remove the show/hide toggle for them; isn't it just clutter? Does anyone currently use it to hide synonyms, which are shown by default? This, that and the other (talk) 02:25, 4 September 2023 (UTC)

I use them usually. DCDuring (talk) 16:36, 4 September 2023 (UTC)

Agreed on the hypernyms and hyponyms: hypernyms, especially, can become be truly massive. While it's true that they should, in such cases, be under their own header, there are too many contributors whose sole purpose in life is to scour the dictionary for such things and no easy way to catch the progression from a few to planetary size in a timely manner. Chuck Entz (talk) 02:59, 4 September 2023 (UTC)

FWIW, to your last point: independent of whether we hide or unhide them, it should be possible to make {{hyper}} (and any of the others) add a tracking link or tracking category any time more than N hypernyms are set, so we could easily monitor. (Perhaps the fact that ====Hypernyms==== sections and/or {{hypernyms}} lines lend themselves so easily to so many users adding such low-value crap is a sign we should reconsider how useful they are to begin with. But that's a separate discussion.) - -sche (discuss) 05:29, 4 September 2023 (UTC)

In my experience people also fail to distinguish properly between holonyms and hypernyms, and meronyms and hyponyms. I have not come across any enormous inline hyper/hyponym lists yet, though; there are enormous inline synonym lists on many Latin entries but the current practice does nothing to help that. —Al-Muqanna المقنع (talk) 09:59, 4 September 2023 (UTC)

It's just a matter of time. Once we didn't have many cognates in any etymologies. DCDuring (talk) 16:36, 4 September 2023 (UTC)

OK, I tried to make coordinate terms and alt forms visible by default, but it doesn't seem to have worked(?). (BTW are all of MediaWiki:Gadget-VisibilityToggles.js, MediaWiki:Gadget-visibilityToggling.js and MediaWiki:Gadget-defaultVisibilityToggles.js still used and non-redundant or could any be consolidated?) - -sche (discuss) 10:10, 5 September 2023 (UTC)

Works for me @-sche (now anyway). —Al-Muqanna المقنع (talk) 14:33, 5 September 2023 (UTC)

MediaWiki:Gadget-visibilityToggling.js is the old version and isn't a gadget anymore (visibilityToggling.js isn't anywhere in MediaWiki:Gadgets-definition) and isn't used by any user (search for user: insource:"visibilityToggling.js"). Pinging User:This, that and the other, who did an experiment making the script a no-op. — Eru·tuon 00:07, 7 September 2023 (UTC)

@Erutuon yes, I was just being cautious. It can probably be deleted. This, that and the other (talk) 00:14, 7 September 2023 (UTC)

@This, that and the other: Yep, deleted. — Eru·tuon 18:46, 7 September 2023 (UTC)

This works in {{head}} but for some reason templates using Module:tl-headword, can't have the translits disabled (tr=-, or any manual transliteration) when the entry is in Baybayin script. Working in Latin script entries though. I would like to request assistance on how to enable manual transliteration on tl-headword but still have automatic transliteration when left blank. Thanks! Ysrael214 (talk) 03:46, 4 September 2023 (UTC)

@Ysrael214 This might be due to an override-translit setting, which in general prevents manual translit from being entered; but it seems to me that |tr=- should still be respected in override-translit languages. User:Theknightwho has redone this handling from what it used to be; maybe they can look into this a bit. Benwing2 (talk) 23:55, 6 September 2023 (UTC)

We have a long list, at MediaWiki:Common.css#L-594, of codes which are set to font-style: normal;. We then also have separate sections for i.Deva, i.Grek.mention, i.polytonic.mention, i.Polyt.mention, .ib-comma, .ib-content i, .ib-content em, .use-with-mention i, .form-of-definition-link, and .mention i, i .mention, which do only the same thing. We could reduce the size of the .css file (which is downloaded for all users) by combining these into the main list — or at least combining i.Deva and the i.Grek/Polyt.mentions into the list of script codes, and combining the .ib and use-with-mention i and form-of and .mention i entries into a second list of non-script-code things that are also not italicized. Downside is that this would move .ib-comma away from other .ib- styles, and use-with-mention .mention away from other use-with-mention styles, etc, although since you can just use the search function to find the relevant line, I don't see this is a major problem. Should we consolidate the sections and save everyone a few bytes, or keep them where they are? (We could also consolidate a number of sections which all do nothing but font-style: italic.) TTO has done a good job of whittling the file down from a high of 50,000 bytes (and an average, since about 2016, of ~44,000) to 41,980; maybe with a little more work we can get it under 40k. - -sche (discuss) 20:20, 4 September 2023 (UTC)

@-sche I think as long as you don't change the actual display, optimizing the CSS is fine. Benwing2 (talk) 23:56, 6 September 2023 (UTC)

The main part of the code that can be removed is the part relating to romanization tables. As currently written, this styling is only used by a couple of pages in the Wiktionary namespace. However, there are other pages that have the same styling hard-coded as inline CSS, so some kind of solution is needed. Once that's sorted, we will definitely be able to get it under 40 KB (noting that MediaWiki minifies the CSS for delivery to users, so the effective size is much less - but it's still good to remove old cruft for our own ease-of-maintenance purposes if nothing else). This, that and the other (talk) 10:27, 7 September 2023 (UTC)

After phab:T316908 this default gadget partly broke in new Vector, displaying "Citations" tab incorrectly; in different places unpredictably; not working in the "Citations" namespace.

You need to replace

	var portlet = document.getElementById('p-namespaces') || document.getElementById('p-cactions');

with

	var portlet = document.getElementById('p-associated-pages') || document.getElementById('p-namespaces') || document.getElementById('p-cactions');

and

	var portlet = document.getElementById('p-namespaces') ? 'p-namespaces' : 'p-cactions';
	var pl = tabs = mw.util.addPortletLink(portlet,
		mw.util.getUrl(page),
		msgs,
		'ca-nstab-' + msgroot,
		msgs,
		'3',
		portlet === 'p-cactions' ?
			(document.getElementById('ca-edit') || document.getElementById('ca-viewsource')) :
			null
	);

with

	var portlet = document.getElementById('p-associated-pages') || document.getElementById('p-namespaces') || document.getElementById('p-cactions');
	var pl = tabs = mw.util.addPortletLink(
		portlet.id,
		mw.util.getUrl(page),
		msgs,
		'ca-nstab-' + msgroot,
		msgs,
		'3',
		portlet.id === 'p-cactions' ?
			(document.getElementById('ca-edit') || document.getElementById('ca-viewsource')) :
			null
	);

I tested the updated code for citations in new Vector, old Vector, Monobook and Timeless. JWBTH (talk) 21:03, 4 September 2023 (UTC)

Done! Thanks for the assistance. This, that and the other (talk) 12:27, 6 September 2023 (UTC)

Hi everyone. Does anyone know if and how I can reference multiple pages of the same book using {{cite-book}} without creating a whole new entry in the ===References=== section?
To explain: if I use this kind of syntax
* <ref name="RandomName">{{cite-book||year=0000|author=Author Name|title=Work Title|page=5}}</ref>
* <ref name="RandomName"/><ref name="RandomName2">{{cite-book||year=0000|author=Author Name|title=Work Title|page=55}}</ref>
I get

with the ===References=== section looking like this

1. ↑ ^{1.0 1.1} Author Name (0000), Work Title, page 5
2. ^ Author Name (0000), Work Title, page 55
   

Is there a way to reference multiple pages (or page ranges) in the same entry, while avoiding repetition of the book info? —— GianWiki (talk) 10:06, 6 September 2023 (UTC)

@GianWiki Not that I know of. I'm planning on revamping the citation templates to use the quotation module backend, which is much more comprehensive, and as part of that we can maybe talk about how to fix this issue (although we need a standard for how to do this; either to repeat the author and year, or just the author, or write ibid. or something; not sure what the current bibliographic standards call for). Benwing2 (talk) 23:53, 6 September 2023 (UTC)

@GianWiki, Benwing2: We could adopt/adapt w:Template:rp from Wikipedia. --RichardW57m (talk) 11:37, 7 September 2023 (UTC)

Apparently both {{nb...}} and {{...}} allow tooltips, but offer no visual distinction unless one happens to move the cursor over the dots and notice something flashing momentarily. As it is now, the tooltip may as well just have inside jokes for in-the-know contributors. The persons who might most need the tooltips are also those least likely to discover them.

Is there a useful, but not too distracting way of visually distinguishing an ellipsis with tooltip and one without? Could different brackets do it? would it be possible to momentarily flash the tooltip content when the page loads? As the flash would become distracting and even annoying, it could be offered as the default for unregistered users and be turned off for all others or turned off by a gadget. Would some kind of not-too-subtle color difference work? Like blue for a tooltip-present ellipsis, which would take advantage of the fact that most users of wikis are aware of the meaning of blue links. DCDuring (talk) 12:38, 6 September 2023 (UTC)

@DCDuring What is the tooltip used for? I note that there’s an “other forms” option for {{nb...}} that allows you to list a bunch of alternative forms in a way that’s in a tooltip, but that seems like a terrible idea because you can’t see tooltips at all on mobile. As I’m on my phone right now, I’d have no idea if it was there. Theknightwho (talk) 13:21, 6 September 2023 (UTC)

It is used for various things now, especially in citations. The mobile interface has a lot more problems than this. Perhaps tooltips should be suppressed on mobile until the mobile interface is more comprehensively improved. I don't see why the PC interface should be limited to what looks good on the mobile interface. DCDuring (talk) 14:21, 6 September 2023 (UTC)

Every time I've seen people use the tooltip it's been for the text that's being elided (usually in long titles). Almost by definition in such cases I don't think it's relevant for ordinary readers—if it is, it shouldn't have been elided. —Al-Muqanna المقنع (talk) 13:29, 6 September 2023 (UTC)

What you describe is the default suppression of subtitles, publishers addresses, etc. In the passage text of a citation it can be handy to have more of the context available than what should be displayed routinely. A user of our entries may well be curious or skeptical about our decisions about what to elide. Should we force them to search the web, especially in those cases where we don't provide a pageurl? DCDuring (talk) 14:21, 6 September 2023 (UTC)

If no URL is provided then they have to search the web anyway. In general I believe citations should be limited to the info that is needed to easily find the source provided, so (again by definition) the extra material should either be hidden because superfluous or not hidden to begin with. I don't think there is any real benefit to reproducing 5-line-long early modern book titles, for example, and if some editors insist on putting them somewhere in the code I doubt anything much is lost by hiding it. On the whole I don't think it would be beneficial to have this kind of extended info visible by default to any group of users. Another typical case is hiding generic subtitles such as "A Novel", "A Comedy" etc., or indeed more extended ones, and in those cases it's often easier to find info on the relevant work by searching without the subtitle. —Al-Muqanna المقنع (talk) 14:27, 6 September 2023 (UTC)

@Benwing2: When using {{w}} (or “w:” in a quotation template) to link to a Wikipedia article, ⟨‘⟩, ⟨’⟩ and ⟨“⟩, ⟨”⟩ should be automatically changed (in the link, not the display) to ⟨'⟩ and ⟨"⟩ because Wikipedia does not use them. J3133 (talk) 14:23, 6 September 2023 (UTC)

Support. I know some people don't like curly quotes anyway but if you are using them it's annoying to have to write stuff like {{w|Harper's Magazine|Harper’s Magazine}}. —Al-Muqanna المقنع (talk) 15:54, 6 September 2023 (UTC)

Another useful addition for {{w}} would be to automatically handle (for info like author names that isn't in the source itself), since unless you enter the brackets as HTML entities it collides with the markup for URLs and makes various kinds of mess. I have seen quite a few cases where people have entered stuff like {{w|John Smith|}}, which in a quotation template currently produces something like:

(Can we date this quote?), , (Please provide the book title or journal name):

Looks OK at first blush, but if you examine it closely the URL formatting includes the left bracket and excludes the right one (especially noticeable on mobile). —Al-Muqanna المقنع (talk) 15:54, 6 September 2023 (UTC)

I am fine with fixing the bracket issue but I think as long as there are a lot of people opposing the use of curly quotes, we should not make it easier to enter them. The curly quote proposal feels to me a bit like a way of finessing curly quotes into quotations in absence of an actual agreement to do so. Benwing2 (talk) 23:47, 6 September 2023 (UTC)

@Benwing2: Mm, that seems like an odd take, there's no consensus against curly quotes either (the most recent relevant vote showed less support for standardising to plain quotes than to curly quotes), and quite a lot of templates that already use them automatically, so it makes no sense to arbitrarily make it slightly harder to enter them specifically in Wikipedia links. To the extent there is a consensus it is that people are free to use either, so they should be assisted in doing so. —Al-Muqanna المقنع (talk) 23:51, 6 September 2023 (UTC)

(Actually, worth noting that the vote above is about Wiktionary policy pages and I just remembered that WT:QUOTE explicitly prescribes using the same style as the original source in quotations anyway: "As a rule of thumb, the style of quotation marks and apostrophes (straight " or curly “) used in the original should always be used on Wiktionary." And the quote templates already generate curly quotes automatically for chapter/article titles! —Al-Muqanna المقنع (talk) 00:02, 7 September 2023 (UTC))

@Al-Muqanna The {{w|John Smith|}} inside quotation templates is an odd one, and I suspect it's down to some module parsing the wikitext and placing HTML after the first ]] it encounters, meaning that the third ] is treated as plaintext. I'm working on something that can parse wikitext links, and it's able to handle these without issue, so it's possibly going to be easiest to wait until that's rolled out since the logic of when a closing ] should be included in the alt text is not particularly straightforward to achieve with conventional Lua patterns. @Benwing2 Just FYI, this is a good example of the kind of issue that will be simpler to fix efficiently with the postprocessing parser, since it's simply a case of making sure the wikitext alt text handlers are correct, and it creates no additional work if it's not relevant to an input. Theknightwho (talk) 12:03, 22 September 2023 (UTC)

As part of a reworking of Persian, Module:fa-translit was moved to a new name yesterday. Nothing wrong with that- but... Balti uses Module:fa-translit for transliteration of its Persian-script forms and now all of them are either in CAT:E with module errors or will be the next time they're edited and the transclusion updates. Can someone please figure out which module it should use and update the data modules so that we get transliteration instead of module errors? @Sameerhameedy. Chuck Entz (talk) 15:09, 6 September 2023 (UTC)

there's not a lot of documentation of Balti, or how its alphabet works. But based on this paper from the Institute of Central Indian Languages Balti should probably use Module:ur-translit. Also the old Persian transliteration module is not included in any templates, so the change needs to be made by a template editor or an administrator at Module:languages. سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 17:30, 6 September 2023 (UTC)

@Chuck Entz @Sameerhameedy I changed the relevant language module to use the new name, until we are in agreement to change its translit scheme. Benwing2 (talk) 23:50, 6 September 2023 (UTC)

There's been a lot of discussion over the years of the oddities that result from certain names being in one top-level category while others are in another top-level category that uses a completely different naming system ("en:" vs "English"). E.g. Vadym's top-level category is Category:Names by language, whereas Sergei's top-level category is Category:Names, while Vladimir is in both. Following lengthy RFM discussions linked at Module talk:names, excarnateSojourner wrote some code to move things like Sergei from "Category:en:Russian male given names" to "Category:English male given names transliterated from Russian" (compare "Category:English male given names from Russian"), as part of having one top-level category with one naming scheme, but we need to make sure autocat and the rest of out infrastructure can handle the new names: what needs to be updated? - -sche (discuss) 04:59, 7 September 2023 (UTC)

@-sche I may be able to work on this eventually but there's a lot going on now, my apologies. Benwing2 (talk) 21:20, 23 September 2023 (UTC)

Can someone move all the Taos entries which use ’ (curly quote) to ʼ (modifier letter apostrophe) per WT:RFM#Entries_in_CAT:Taos_lemmas_with_curly_apostrophes? - -sche (discuss) 06:04, 7 September 2023 (UTC)

When I create a new (English) entry, the accelerated plural from WT:ACCEL shows as a blue link, like an existing entry, even though the entry does not in fact exist. They used to be green until recently. Note I'm using some old stylesheet like Monobook or something. Can anyone repro or fix? Equinox ◑ 12:34, 7 September 2023 (UTC)

The styling for such links was recently moved; perhaps some old skin missed being updated to use (or for some reason doesn't play well with) wherever they're now located? Or it's a temporary caching issue? @This, that and the other. FWIW it works as expected for me; when the target page doesn't exist, the links are green when I'm logged in, and red when I'm logged out, until they're created, at which point they turn blue. - -sche (discuss) 15:23, 7 September 2023 (UTC)

I can provide Google Chrome "Inspector" CSS info if someone tells me what they need. Equinox ◑ 17:19, 7 September 2023 (UTC)

@Equinox it's because you're loading the WT:ACCEL gadget in a very ancient way, via a line on User:Equinox/monobook.js. The modern way (since 2011 or so) has been to go to Special:Preferences, Gadgets tab, and turn it on there. It seems that there are still a substantial number of users loading WT:ACCEL in this way; most are old users who are no longer active, but I will need to think of something to help those who are still active, like yourself. This, that and the other (talk) 22:47, 7 September 2023 (UTC)

This should be resolved now with no action required on your part (or anyone else's). The User:Conrad.Irwin/creation.js script now turns on the WT:ACCEL gadget for you. This, that and the other (talk) 23:33, 7 September 2023 (UTC)

"resolved with no action required on your part" is called backward compatibility and thank you for doing it. Haven't tested yet, but I bet I'm about 90% of your usership by edit volume. Equinox ◑ 02:40, 8 September 2023 (UTC)

The former default, which is referred to in the documentation does not work, as one of the two examples given shows, so that one must type the same term in twice. Why? DCDuring (talk) 17:34, 7 September 2023 (UTC)

@DCDuring It was a bug, which I’ve now fixed. Theknightwho (talk) 18:01, 7 September 2023 (UTC)

Apparently all gadgets run by default on the mobile skin of Wiktionary now (en.m.wiktionary.org), whereas they used to only run on the desktop version unless target=mobile or target=desktop,mobile was specified in MediaWiki:Gadgets-definition. (See this version of the page for the gadgets that used to be enabled on mobile.) If you notice one of your installed gadgets doing something bizarre on mobile, it can be disabled on mobile by an interface administrator with an edit like this until someone can figure out how to make it behave correctly. — Eru·tuon 22:18, 7 September 2023 (UTC)

@Jon (WMF) I am pinging you so you are aware of the chaos that this change has caused for us. You are a software engineer (as am I), so you should know to (a) be careful, (b) communicate breaking changes to your audience before making them. Apparently you did neither of these things. Can you elaborate why? Benwing2 (talk) 07:34, 8 September 2023 (UTC)

To be fair to the WMF folks, this was communicated three times in Wiktionary:Wikimedia Tech News/2023: first in issue 2023-06 from February as an advance warning, and again in issues 2023-26 and 2023-27 from July to advise of the impending rollout. IMHO we should get Tech News delivered here to the Grease Pit, as this newsletter is WMF's main communication channel for breaking changes.

And yes, this has actually been in effect since July. I'm somewhat perplexed as to why others are only just noticing it. This, that and the other (talk) 12:42, 8 September 2023 (UTC)

All right, my apologies. I think my frustration stems partly from the general lack of response of the Wikimedia developers to Wiktionary-specific concerns, and the tendency to close as "will not fix" any Phabricator tickets we file. Yes, Wiktionary is smaller than Wikipedia but not that small. Benwing2 (talk) 21:57, 8 September 2023 (UTC)

@This, that and the other: Thanks, I looked through some of the recent Tech News on Meta-Wiki, but didn't find anything. I haven't been following them lately. I think they used to be posted in the Grease Pit at one point. — Eru·tuon 21:58, 8 September 2023 (UTC)

Hi @Benwing2, firstly sorry for the chaos that has been caused to you. We do know to be careful and we did communicate these breaking changes. I'm sorry these messages didn't reach you, communication across all our wikis is challenging. We recently created a mw:Stable_interface_policy/Frontend to document how Wikimedia developers communicate these changes so this should help set better expectations about what and how this should happen. All developers are expected to follow these guidelines, so please read through and check mw:Stable_interface_policy/Frontend#Using_code for the expectations we currently have on consumers of code like yourself.

Since communication is clearly an area we can improve, there has been discussion about having a mailing list to announce these sort of changes since the current communication mechanisms clearly do not reach the right audience. Since you missed our communication via tech news, if you have any thoughts on a mailing list or other ways we could be communicating to developers like yourself without tech news in a way that scales across all our projects I'd love to hear from you on mw:Topic:Xlrhitipsnlphmph.

Thanks for the ping and sorry again. Let me know if there's anything further I can do to help. Jon (WMF) (talk) 18:21, 18 September 2023 (UTC)

It seems that the function is not added to the template yet. It is possible to suppress tone sandhi in Hokkien by the character "#" but not in Teochew. Mahogany115 (talk) 10:01, 8 September 2023 (UTC)

I noticed a quote at east ("We, in the west...") sitting outside of the set of things that are recognized and collapsed as quotes, and in looking into how it got that way (this edit, @JeffDoozan), I also noticed this edit terminated a quote too soon, leaving the ISBN dangling on its own line (since anything placed on the same wikitext line as a quote template gets shunted to the next line), and leaving the quote itself outside the template; I wonder if that is also how some metadata at common sense (TR) also ended up outside the template. I think it'd possible to find other cases where these things happened by searching for:

1. quote- or RQ- templates with extra text on the same line as, but outside of, the template (to find the second issue)
2. cases where a quote template ends (}}) and then the following wikitext line starts with |someParameter= (to find some instances of the first issue)
3. cases where there are more { than } or vice versa (to find other instances of the first issue, and probably a lot of other things caused by miscellaneous editors that we'd like to know about and fix)

- -sche (discuss) 20:14, 8 September 2023 (UTC)

@-sche:, I'll check for and fix any similar bad bot edits. On the first edit, the bot (very, very incorrectly) matched multiple lines and then wrapped them in a quote template, so the total number of {{ }} would have been balanced. Then someone partially fixed the bad quote which set the stage for the second edit, where it (arguably correctly) converted plain text to a quote and then ignored the random |param= lines after the plaintext. As far as the cleanup lists go, I've already got #1 and #3 here and here. I think #2 should be extremely rare, but I'll check it out. JeffDoozan (talk) 20:38, 8 September 2023 (UTC)

@LlywelynII tried to talk about Longgang's origin here: diff. I tried to use Template:zh-l here: diff; my edit is arguably worse. Both of these are ugly results. Is there an intelligent way to do this? Thanks. --Geographyinitiative (talk) 21:30, 8 September 2023 (UTC)

@Geographyinitiative, LlywelynII: You can use {{l}}/{{m}} for Chinese with automated pinyin and simplified form support (this was a thing added a few months ago) - I've made the changes accordingly. As a general principle, non-English words should always be wrapped in templates ({{l}}, {{m}}, {{lang}}, etc.), and this is especially the case for Chinese to allow the browser to use the correct fonts, and for the modules to generate pinyin and simplified forms. – wpi (talk) 12:58, 11 September 2023 (UTC)

Agreed. We should never be using bare links like this. Theknightwho (talk) 14:43, 11 September 2023 (UTC)

See also Talk:五つ子. Basically, the ruby should be 五(いつ)つ子(ご) (itsutsugo), but it's displaying incorrectly as 五(い)つ子(つご) (itsutsugo). Since {{ja-noun}} doesn't allow editors to specify the kanji string, and instead just pulls from the pagename, any attempts at manually adding the % markers to force correct parsing just fail out, since the pagename doesn't have any % characters. ‑‑ Eiríkr Útlendi │^{Tala við mig} 21:31, 8 September 2023 (UTC)

@Eirikr Pinging User:Theknightwho who has done some work on this code. Benwing2 (talk) 22:00, 8 September 2023 (UTC)

The ruby relies on the {{ja-kanjitab}} template now. —Fish bowl (talk) 02:32, 9 September 2023 (UTC)

This popped up in CAT:E today (in my time zone), along with assorted Beer parlour pages that invoke it directly like its documentation page does. After going through the transclusion list for Module:family tree/documentation and previewing Module:family tree/documentation from old revisions of all of those modules with edits over the last 24 hours or so (for the record: Module:families/data, Module:languages/code to canonical name, Module:languages/data/exceptional, Module:languages/data/2, Module:languages/data/3/p, Module:languages/data/3/y, and Module:string utilities), I think I've narrowed the cause down to this edit to Module:families/data, but I can't see anything wrong with it. Can someone figure out what's really wrong and fix it? Thanks! Chuck Entz (talk) 05:34, 9 September 2023 (UTC)

@Chuck Entz: There are a couple of caches in Module:families/canonical names and Module:families/code to canonical name that were added by User:Theknightwho in April that needed to be updated. Unfortunately there doesn't yet appear to be a Javascript button to update them automatically as there is for regular languages, and the consistency check code doesn't seem to know about them. Benwing2 (talk) 18:31, 9 September 2023 (UTC)

@Benwing2: I've added some more checks of Module:families/canonical names and Module:families/code to canonical name, so at least the errors are visible now. All of these derivative data modules should be updated by MediaWiki:UpdateLanguageNameAndCode.js as well when I feel like making it do that. — Eru·tuon 23:36, 9 September 2023 (UTC)

@Erutuon Thanks! The errors are actually spurious; the code you added needs to also check Module:families/data/etymology. Benwing2 (talk) 01:00, 10 September 2023 (UTC)

BTW User:-sche User:Vahagn Petrosyan User:Theknightwho I am going to eliminate the nonstandard etymology-only family codes OIr. and MIr. in favor of their canonical names ira-old and ira-mid. This is related to the elimination of nonstandard etymology-only language codes. Benwing2 (talk) 01:02, 10 September 2023 (UTC)

Following this, this vote authorized a bot to suppress anyone who hasn't edited in two years from the Babel categories. But when I looked through Category:User ja-N for active native Japanese-speakers to ping to another discussion, they were swamped by people who've been inactive since 2008, 2010, 2015. Anyone feel like making a bot run? If not, I'll at least manually remove users from the ja category; if we manually remove users every time we find ourselves looking through some category for active users, that's at least partially as helpful. For example, manually removing anyone whose last edit was before ~2020 just brought that category down from 64 to 38 users. (I had some other ideas earlier this year, including that if we didn't want to completely remove users from the categories, we could overwrite what they were sorted as, so instead of being sorted under "F", an inactive User:Foobar would be sorted under e.g. "⏳".) - -sche (discuss) 16:29, 10 September 2023 (UTC)

Definitely support regular bot runs to save manually combing through them. Checking the lists at Module:workgroup ping/data would probably also be useful. —Al-Muqanna المقنع (talk) 16:52, 10 September 2023 (UTC)

Yes please! Vininn126 (talk) 16:55, 10 September 2023 (UTC)

{{Babel}} should have nocat, so the template does not need to be removed, as you are all about the categories. If one reviews someone’s old edits the information of his claimed languages may be relevant. Fay Freak (talk) 01:46, 15 September 2023 (UTC)

It's still useful to be able to check the category. Vininn126 (talk) 08:03, 15 September 2023 (UTC)

I don’t know how but ok, one can instead split the categories with |inactive=. I just had seen that -sche had commented out two Babel boxes. Fay Freak (talk) 15:31, 15 September 2023 (UTC)

Nobody was proposing to remove the template itself. But the vote @-sche mentioned above mentioned a parameter |inactive=yes, it doesn't look like that was ever implemented? —Al-Muqanna المقنع (talk) 08:23, 15 September 2023 (UTC)

Yeah, it would be ideal if someone implemented that and then bot-added it. I can undo the several Japanese-speakers and two Romanian-speakers whose Babels I've simply commented out. - -sche (discuss) 15:48, 15 September 2023 (UTC)

• Is this the right forum for this question? I'd have expected BP. DCDuring (talk) 12:15, 15 September 2023 (UTC)

{{der|lang|lang}} adds entries to Category:LANG twice-borrowed terms, but it should instead be Category:LANG twice-derived terms, if I'm not mistaken. @Benwing2, Leasnam -- Sokkjō 19:14, 10 September 2023 (UTC)

Yes, agreed. Also the reason why I hesitated creating it. Leasnam (talk) 19:23, 10 September 2023 (UTC)

On my understanding of how the templates are meant to be used, the existing setup is correct. My interpretation is that {{bor}} is only to be used with a borrowing into the entry language, otherwise you end up with wrong categorisation. So a twice borrowed term will use {{bor}} for the first borrowing (from the second language to the entry language) and then {{der}} for the second borrowing (from the entry language to the second language).

And even if I'm wrong, I'm dubious that there are any terms that are "twice-derived" but not "twice-borrowed". Surely borrowing is a necessary condition for a term to be "twice-derived". Can you give an example of a term that is "twice-derived" but not "twice-borrowed"? This, that and the other (talk) 23:46, 10 September 2023 (UTC)

Perhaps a borrowing from a Romance language into some form of Latin would be an example, but "twice-derived" doesn't sound very descriptive of the actual processes. After all, there might be several stages of inheritance before it was borrowed back, so such a term would be "derived" more than twice. Not that "twice-borrowed" is any better in that respect. Basically, these are terms that are "borrowed back" into the same language they came from after going through any combination of intermediate steps, but I can't think of an unambiguous attributive version of that- "re-borrowed" could mean that it was borrowed twice into the same language. Chuck Entz (talk) 00:53, 11 September 2023 (UTC)

I suppose it could be called "LANG terms borrowed back into the same language" or something; it would be longer but maybe less confusing. Benwing2 (talk) 02:32, 11 September 2023 (UTC)

This is the entry that brought this up, Reconstruction:Proto-West Germanic/kamisi. When a Germanic term gets borrowed into Latin, it quite commonly gets later reborrowed back into Germanic. Category:LANG reborrowed terms could work as a category name. Another solution might be to create a wrapper template called {{reborrowed|lang1|lang2|term}} for use in such cases where you can have Category:LANG1 terms reborrowed from LANG2. -- Sokkjō 04:45, 11 September 2023 (UTC)

Ironically, this is an actual twice-borrowed term, but isn't being funneled into that category. -- Sokkjō 01:26, 12 September 2023 (UTC)

Surely that would only be twice-borrowed if Latin sclarēia was borrowed from PWGmc, which it does not appear to be. Or am I missing something? This, that and the other (talk) 08:28, 13 September 2023 (UTC)

@This, that and the other: The Germanic is borrowed from the Latin twice, frist as *sklaregā and secondly as *skarlejā. What else would be be called? -- Sokkjō 17:53, 18 September 2023 (UTC)

Oh, that's a {{doublet}}. @Benwing2 Chuck Entz perhaps we really do need a better term than "twice-borrowed", if it confuses even our experienced contributors! Wikipedia uses reborrowing but their article is poor in quality. Benwing's idea of a more descriptive name is better. This, that and the other (talk) 00:38, 19 September 2023 (UTC)

Yeah, searching Google web and Google Books for the phrase "twice-borrowed", trying to figure out where we got that term from, I notice most of the hits are irrelevant, many are about cases like sclarēia that are not "twice-borrowed" in our sense but simply "borrowed on two occasions" (fun fact, some terms have been borrowed even more times), and some of the hits which do use our sense are saying things like "apparently this is called 'twice-borrowed'" as if they'd just learned it (from us?). Some clearer category name could be an improvement. Maybe "LANG terms borrowed back into LANG", with "...borrowed back into the same language" for the top-level category? I'm just thinking repeating the LANG might help avoid people understanding "LANG terms borrowed back into the same language" as meaning "the English words in this category were borrowed from , and then later borrowed them back into ". - -sche (discuss) 17:01, 23 September 2023 (UTC)

Yes, I'd be very supportive of this name change. I've posted at WT:RFM. This, that and the other (talk) 02:32, 24 September 2023 (UTC)

@This, that and the other: Sure, it is a doublet -- and makes use of {{doublet}} on the page -- but a doublet can be once inherited and once borrowed as well. -- Sokkjō 17:14, 23 September 2023 (UTC)

Since at least 2017, there has been a desire to get the PageNotice MediaWiki extension installed on this wiki. This extension allows a common piece of content to be displayed at the top (or bottom) of every page in a namespace. For example, we could use it to display {{reconstructed}} at the top of pages in the Reconstruction namespace without having to actually add the template to every single page. We could even do something similar - adding a small box explaining what the pages are for - on other specialised namespaces like Citations or Sign gloss, if we were so inclined.

Anyway, when it comes to setting up new extensions, it seems that nobody is going to do this sort of thing for us. Somebody has to be willing to get their hands dirty (the years of discussions at phab:T61245 may be of interest to some). So I decided to step up and do it.

For now, I have arranged for the PageNotice extension to be enabled at the Beta English Wiktionary. Currently it is displaying a notice at the top of all Reconstruction: pages, for example, . The message itself can be found at .

Please feel welcome to experiment with PageNotice on Beta over the next week or two. I'm happy to grant admin rights at Beta to known users here; just create your own account (it doesn't use the same accounts as this wiki) and ask me for the admin bit by pinging me here. Ping @Victar who was a proponent of this extension's installation back in the day. This, that and the other (talk) 09:23, 12 September 2023 (UTC)

Thanks for taking up the mantle with this. I've been reading the comments on Phabricator over the past weeks, and saw the same frustration @Erutuon and I had back then. Figures doing the "wrong" thing is the only way to get anyone's attention in a broken system. --{{victar|talk}} 15:32, 12 September 2023 (UTC)

Wow, that ticket is a bureaucratic horrorshow, for just 100 lines of code. Jberkel 11:59, 14 September 2023 (UTC)

Hi, could someone with the authority please update the module:Unicode data? There is a new block, CJK Unified Ideographs extension I from U+2EBF0 to U+2EE5F. Additionally, U+31EF should have the script common and category So, U+2FFC to U+2FFF script common and category So and U+2EBF0 to U+2EE5D script Hani and category Lo. Thank you. 193.2.154.13 12:28, 13 September 2023 (UTC)

I'll update the filter so that entries using these characters can be created. Theknightwho (talk) 12:47, 13 September 2023 (UTC)

Hi, does anyone know where the code is that converts the code for an IPA pronunciation (e.g. {{bg-IPA|банка}}) to the actual IPA pronunciation (bɐŋkɐ)? I'm trying to train an AI to convert spelling to pronunciation from the database dumps and would rather avoid webscraping the pronunciations. 195.194.22.58 14:53, 13 September 2023 (UTC)

MOD:bg-pronunciation Vininn126 (talk) 15:10, 13 September 2023 (UTC)

And if you were using Bulgarian as a random example, the complete list of modules is at Category:Pronunciation modules. This, that and the other (talk) 00:33, 14 September 2023 (UTC)

Should Urdu ۂ be linked differently or removed from links, e.g. بَرْطَانِیَۂ (bartāniya-yi) to بَرْطانِیَہ (bartāniya) as in بَرْطَانِیَۂ عُظْمیٰ (bartāniya-yi 'uzmā)?

Compare with Persian کُرهٔ جُنوبی (kore-ye jonubi) where هٔ is linked to ه. ۂ looks the same as هٔ but the former is one symbol.

@Sameerhameedy, @Fenakhay, @نعم البدل, @Benwing2. Anatoli T. ^{(обсудить}/^вклад) 07:35, 14 September 2023 (UTC)

@Sameerhameedy, @Fenakhay, @نعم البدل, @Benwing2: After a few edits to Module:languages/data/2: I think I got this right.

• ۂ (h-yi) "U+06C1" redirects to ہ (h), only for Urdu, not Persian (but may need to be added for other languages).

Should the handling in Urdu ALSO exist as in Persian, e.g. هٔ (U+0647 + U+0654) links to ه (U+0647)?

Current Urdu:

from = {"هٔ", "ۂ"}, -- character "ۂ" code U+06C2 to "ه" and "هٔ" (U+0647 + U+0654) to "ه"

to = {"ہ", "ہ"},

Current Persian:

from = {"هٔ"}, -- character "ۂ" code U+06C2 to "ه"

to = {"ه"},

Sorry for many pings! Anatoli T. ^{(обсудить}/^вклад) 02:06, 15 September 2023 (UTC)

@Atitarev: If it's possible, I would keep ۂ (h-yi) in links when it's used in a compound, but redirect to ہ (h) otherwise. So بَرْطَانِیَۂ عُظْمیٰ (bartāniya-yi 'uzmā) should be as it is, but بَرْطَانِیَۂ (bartāniya-yi) should redirect to بَرْطَانِیَہ (bartāniya). نعم البدل (talk) 15:55, 15 September 2023 (UTC)

@نعم البدل: Thanks, I missed your ping, since the signature and the ping should be in one edit.

In any case,

1. بَرْطَانِیَۂ عُظْمیٰ (bartāniya-yi 'uzmā) links to برطانیہ عظمی
2. بَرْطَانِیَۂ (bartāniya-yi) links to برطانیہ, just like بَرْطانِیَہ (bartāniya)

In both cases, ۂ is not in the page title but is part of the headword in the first example. It is treated as a diacritic and converts ۂ to ہ on links, which was the idea.

It works basically identical as a Persian example with هٔ linking to ه in کُرهٔ جُنوبی (kore-ye jonubi) (which links to کره جنوبی, note missing "هٔ") but it's for similar-looking but different symbols. Anatoli T. ^{(обсудить}/^вклад) 04:53, 22 September 2023 (UTC)

@Atitarev: - Yeah, actually, that's fine - keep as it is. I forgot that sometimes ۂ is also substituted with ـیہِ so it's best to just limit ۂ to headwords. نعم البدل (talk) 14:45, 22 September 2023 (UTC)

Box templates of maintenance purposes like {{rfquote}} have the noprint class. Does it make sense to add it to the templates based on {{maintenance line}}, like {{rfv-sense}}? JWBTH (talk) 10:45, 14 September 2023 (UTC)

Currently, there is only 1 conjugation template for Okinawan which is for the irregular palatal changing verbs. We should make (a) new template(s) for the regular conjugations and the special verbs (do, come…) Je suis une paille (talk) 14:42, 15 September 2023 (UTC)

If you are familiar with Okinawan conjugation patterns, by all means, please build those out. I currently lack both the expertise and the resources. ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:45, 15 September 2023 (UTC)

I could find/provide the resources, but the module-building would be the biggest issue. I'd like to build one out for Jeju too, but looking at Module:ko-conj gives me nightmares. AG202 (talk) 19:05, 15 September 2023 (UTC)

I’m sorry this sounds like a stupid question but I’m pretty new to this, how do I make a template? The wiktionary help didn’t really help me😅 Je suis une paille (talk) 02:49, 16 September 2023 (UTC)

@Je suis une paille you could try copy-pasting the code of Template:ryu-conj-palatal to Template:ryu-conj-regular or whatever you want it to be called, and making the necessary changes. Mellohi! might be able to assist. This, that and the other (talk) 07:51, 16 September 2023 (UTC)

I frequently notice definition-line templates being used in eymologies, e.g. I just now spotted {{clipping of}} in shi. Anyone up for making a list of cases where such templates (Category:Definition templates) are in etymology sections, and seeing what we could then bot-replace with etymology-templates? (Might also want an edit filter to warn people against adding more, but maybe that'd be too 'expensive'.) - -sche (discuss) 15:45, 15 September 2023 (UTC)

I'm on the wrong computer now, but I could easily generate such a list in a couple of days' time. Maybe someone else will beat me to it.

It's worth noting that some form-of templates don't seem to have an etymology equivalent, such as {{inflection of}}. In fact, only eight form-of templates are explicitly documented as having an etymology equivalent: . This, that and the other (talk) 07:58, 16 September 2023 (UTC)

Here's a list, split by template. Some templates might be good candidates for bot fixes, but many may need some manual cleanup. JeffDoozan (talk) 17:43, 16 September 2023 (UTC)

Pursuant to the mergers of the literary Prakrits and others into a single Prakrit language, @Benwing2 has asked me to review the replacement of {{desctree}} by {{desc}} in 𑀕𑁄𑀳𑀽𑀫 (gohūma) because of a self-reference in the descendants table, which previously led to an infinite loop. Can someone therefore direct me on how one is supposed to handle {{desctree}} and a convention that constituent literary Prakrits are etymology languages descended from a parent common 'Prakrit' language? There may be the immediate complication that the forms in specific literary Prakrits and thus etymology-only languages, Sauraseni Prakrit and Maharashtri Prakrit, are alleged to be the same as the 'Prakrit' form in whose entry the problem arises, though I see no evidence to support that highly credible assertion. (Moreover, if the word existed in Sauraseni Prakrit, that fact should be recorded in the headword line. It isn't.) The solution might just be that {{desc|pra-mah|𑀕𑁄𑀳𑀽𑀫}} should be replaced by {{desc|pra-mah}} and {{desctree}} be applied at a lower level. The documentation of {{desc}} seems to imply that one should use {{desc|pra-mah|alt=𑀕𑁄𑀳𑀽𑀫}} rather than simply omit the descendant, but our documentation would not survive a competent quality audit. @Benwing2, AryamanA.

There is of course the further complication that the physical lemma Prakrit 𑀕𑁄𑀳𑀽𑀫 (gohūma) is merely a Wiktionary inference - barring an amazing accident of preservation, no quotation or contemporary mention is possible for the entry. (That hasn't stopped quotations being reconstructed.) --RichardW57 (talk) 22:32, 16 September 2023 (UTC)

@Benwing2, Theknightwho There has been something like a 30% slowdown in the CPU time generation of Prakrit declension since June this year. I don't know when it happened; it's now causing the generation of Module:pra-decl/noun/gallery/documentation to run out of CPU time. I don't think Benwing2's unnecessary changes to the declension module is the cause, as it only lengthens a few strings used in the process start up. The declension makes fairly intense usage of standard Prakrit transliteration from Brahmi, Devanagari and Kannada, and of transliteration from Latin by Module:typing-aids with the shortcut systems designated "sa", "inc-pra" and "inc-pra-Knda". The data files Module:typing-aids/data/sa etc. have not been changed since a speed up in declension was achieved in June this year. Any suggestions as to what may have gone wrong?

I think I may be able to achieve a significant speed up by condensing the typing-aids data files. The other alternative is to split the gallery by script. --RichardW57 (talk) 00:59, 17 September 2023 (UTC)

@RichardW57 My only thought is changes to core language modules by User:Theknightwho. More work is being done, which may have slowed things down. It may be possible to speed it up e.g. by caching, but this will increase memory. I don't see a problem with splitting the gallery file; I've had to do that in several cases for test files in my userspace, mostly due to template include size issues but sometimes due to speed issues. Benwing2 (talk) 01:03, 17 September 2023 (UTC)

@Benwing2 I can’t think of any significant changes that I’ve made recently. Theknightwho (talk) 01:06, 17 September 2023 (UTC)

@RichardW57 The current use of Module:typing-aids is a massive kludge that’s not really appropriate, and is likely a major source of problems, as it’s adding a ton of extra work for no obvious reason - can’t the original strings simply be processed directly? Theknightwho (talk) 01:11, 17 September 2023 (UTC)

Yeah, Module:typing-aids intentionally uses a simplistic transliteration method to make things easier, and it's supposed to run only when saving the page ({{subst:chars|sa|...}}). It calls mw.ustring.gsub for every pattern and replacement in the data modules, which is slow because that's a lot of calls across the Lua-PHP interface. An efficient Latin-to-whatever function should probably be developed in a separate module because the architecture of the Module:typing-aids data modules is not designed for optimization. For one thing, the data modules can't use function replacements, which can reduce the number of calls to mw.ustring.gsub (though I'm not sure if that helps for Prakrit or not). I tried replacing require("Module:typing-aids").interpret_shortcuts with function(x) return x end in Module:pra-decl/noun (put require("Module:typing-aids").interpret_shortcuts = function(x) return x end into joinSuffix) and previewed Module:pra-decl/noun/gallery/documentation, and the tables finished generating in about 7.5 seconds. So apparently Module:typing-aids is taking up at least 2.5 seconds on that page. — Eru·tuon 02:27, 17 September 2023 (UTC)

@Erutuon, Theknightwho: I think I can achieve a speed up by using substitution tables as an input. Whether we should always use an automatic selection between ustring.gsub and string.gsub I don't know - and it may already be there. There are other tricks we can play - if we convert IAST to Brahmi, it's safe rather than clever to ask Module:links to transliterate back. --RichardW57 (talk) 02:54, 17 September 2023 (UTC)

@Erutuon, Theknightwho: Using substitution tables in the typing-aids data module sa results in the gallery rendering 78 times out of 10 from the module editor, with Lua times in the seven successful cases ranging from 8.85s to 9.64s. It's currently out of cat:E. I'll have to work on the Brahmi script and Kannada script data modules as well. --RichardW57 (talk) 14:02, 17 September 2023 (UTC)

@Erutuon, Theknightwho: I did the same redunction to the number of replacements for modules inc-pra and inc-pra-Knda as well, and timed 11 generations. The Lua CPU times in seconds were, sorted:

7.27, 7.28 7.37 7.45 7.50 7.65 7.69 7.75 8.09 9.48 9.99

So, reducing the number of 'gsub' calls specified in the data modules makes time spent in Module:typing-aids relatively negligible. There is a set of about a dozen calls (one per dependent vowels) that could be reduced to one using the function-determined replacement value. That could be reduced to two calls if we need to squeeze some more time out, at the cost of some obscure code.

Might using table.insert to build the declension table save run time as well as keeping memory usage lower? RichardW57 (talk) 17:23, 17 September 2023 (UTC)

@RichardW57: It sometimes helps with memory usage. It won't help in every case because the total memory usage of the intermediate strings (a, ab, abc, abcd, ...) isn't necessarily less than the memory usage of the array part of the table used to hold the strings being joined with table.concat ({ a, b, c, d, ...}), but I guess it'd help export.show because the first literal string being concatenated is 241 bytes, so every new intermediate string being allocated is at least that many bytes (much more than an entry in the array part of the table). I'm not sure about time, but it's possible that allocating a bunch of longer strings takes longer. One idea that I haven't tried is creating the right size of table by doing local output = {nil, nil, ....} with as many nils as there will eventually be strings in the final version of the table (ideally a power of two because the length of the array portion is doubled when it needs to be lengthened... I think though I don't really understand the Lua 5.1 table-related source code). (Can do mw.log(#output) before the return table.concat(output) to see how many nils.) I think that means the Lua runtime doesn't have to reallocate to lengthen the array part of the table, which takes some time. Another technique is to have local i = 0 and function insert(s) i = i + 1 output = s end to avoid the slight inefficiency of table.insert checking whether it received two or three arguments. Anyway, this is a lot of explanation... I'll give this a try in Module:pra-decl/noun myself and see what happens. — Eru·tuon 21:20, 17 September 2023 (UTC)

The timings on that are a bit mysterious. 11 runs previewing Module:pra-decl/noun/gallery/documentation gave the LUA CPU times in seconds in ascending order:

6.59, 6.73. 6.91. 7.01. 7.15, 7.17, 7.30, 7.52. 8.20, 8.37, 8.69

About half a second better, but worth keeping. Curiously, the Lua CPU time is always less than 9.00s - perhaps these runs were just lucky. --RichardW57 (talk) 23:11, 17 September 2023 (UTC)

@Erutuon, Theknightwho: It's still an intermittent visitor to cat:E. The evaluation of Erutuon's change must have been lucky to avoid random overhead. --RichardW57m (talk) 14:37, 19 September 2023 (UTC)

@Erutuon reduced the set of about a dozen calls to one by a cunning trick for Devanagari, not the most used Indic script in the gallery, and squeezed 0.9s off the timing (run times:

6.12, 6.12, 6.13. 6.17. 6.20. 6.23, 6.24, 6.25, 6.27. 6.33, 6.40)

That's well worth propagating to Brahmi (module inc-pra) and Kannada (module inc-pra-Knda). That experimental 7.5s time reported above was either an unlucky result, trying to format IAST as Prakrit hit significant overheads, or conceivably even total CPU time rather than Lua CPU time. --RichardW57m (talk) 10:31, 20 September 2023 (UTC)

I see that at 1:27 on 17 September, @theKnightwho reversed my replacement of unconditional mw.ustring.gsub by Module:string utilities' gsub, wnich in June 22 single run comparisons reduced run time from 9.997s to 7.763s. I therefore compared the two methods, timed from a preview of editing Module:typind-aids. The results of 12 runs each were:

gsub=mw.ustring.gsub:

5.86, 6.56, 7.01, 7.32, 7.35, 7.55, 7.68, 7.85, 7.89, 8.08, 8.43, 9.65,

gsub=require("Module:string utilities").gsub:

6.03, 6.27, 6.35, 7.07, 7.11, 7.24, 8.17, 8.33, 8.42, 8.45, 8.56, 8.66

The means are the same (means of 6.80 v. 6.83), so it no longer matters which one we use! At least I hope the timings were not affected by other edits going on at the same time - just after the timing completed, the rendering the gallery suffered a Lua time-out, but then the problem went away. --RichardW57m (talk) 14:23, 21 September 2023 (UTC)

@Theknightwho: The main overhead of the module was I think its design as a template extension. That has been bypassed since June '23. Now, I don't like doing everything twice; I would rather not convert the stem from native to Roman and then convert back, because that can sometimes change it, but for the Indian Prakrits that doesn't seem to be a problem - so long as we don't add phonetics into transcription. Stitching the stem and ending together in Prakrit is fiddly, and I think is even fiddlier in an Indic script than in the Latin script. (The problem is hiatus.) Now, it may come to converting it to a more conventional reverse transliteration, but that would mean that we had transliteration to Indic being defined in yet another place, which would be a maintenance issue should we ever track the Wikipedia definition of IAST. (Modern academic IAST is not the same as the original IAST.) I don't like unnecessary proliferation. --RichardW57 (talk) 02:34, 17 September 2023 (UTC)

@Benwing2: The problem with splitting the gallery table comes if one compares tables. With one big page, one would display it in two windows and scroll to bring the two tables one wants to compare into view. If it is split into three, one easily ends up with six windows to control, which is rather more complicated for the reviewer. --RichardW57 (talk) 01:59, 17 September 2023 (UTC)

The timing seems all over the place. It's significantly faster when I preview the page from a Lua editing session! At first I thought someone had already sped things up this morning, but viewing the page directly still loses a third of the last section, 'Mixed Script'. Before, it was losing all the tables in the last section. Perhaps I'm seeing the effect of a mix of CPU speeds. --RichardW57 (talk) 11:03, 17 September 2023 (UTC)

Hi. I'm not exactly sure this is the right section to ask this, but I'll try.
I tried adding the pronunciation for an entry where the realization of the cluster /-ɬt-/ oscillates between , invalid IPA characters (ᵗ) (with dental release), and (assimilated), but the {{IPA}} template does not accept /ᵗ/ invalid IPA characters (ᵗ) as a valid character, despite it being ostensibly part of the IPA. Is there any particular reason for this?
Thanks in advance for your time. —— GianWiki (talk) 08:29, 18 September 2023 (UTC)

The label given to the template is not valid. DonnanZ (talk) 16:15, 18 September 2023 (UTC)

@Donnanz: My bad. Fixed. -- Sokkjō 17:56, 18 September 2023 (UTC)

@Sokkjo: Thanks. The error message didn't prevent my adding to the category. DonnanZ (talk) 18:08, 18 September 2023 (UTC)

• Well, I did fix it, but then @Fenakhay reverted me LMFAO. -- Sokkjō 18:32, 18 September 2023 (UTC)

That's bizarre! DonnanZ (talk) 19:01, 18 September 2023 (UTC)

@Sokkjo: You haven't fixed a thing. Look how many errors there are because of your edits. — Fenakhay ^{(حيطي · مساهماتي)} 19:22, 18 September 2023 (UTC)

@Fenakhay: My edit was a reversion of myself. What specific errors did it cause? -- Sokkjō 19:30, 18 September 2023 (UTC)

@Sokkjo: You deleted CAT:Buildings handling, which is a parent CAT of many categories. — Fenakhay ^{(حيطي · مساهماتي)} 19:32, 18 September 2023 (UTC)

@Fenakhay: I see what happened now. Thanks for restoring it correctly, instead of just reverting me and deleting Category:Bridges. -- Sokkjō 19:39, 18 September 2023 (UTC)

On the sledge page, {{anchor}} is used with the parameter "Et2N". WTF is that about? P. Sovjunk (talk) 21:50, 18 September 2023 (UTC)

"Etymology 2 Noun", presumably. Added here by a Wikipedian. It was surely an attempt to make an {{etymid}} by someone who was accustomed to Wikipedia's {{anchor}} template.

"Et2N" doesn't appear in any other entries so the anchor can be removed. This, that and the other (talk) 00:45, 19 September 2023 (UTC)

Meh, I'm not gonna remove it. I'll probably best ignore anchors. P. Sovjunk (talk) 07:00, 19 September 2023 (UTC)

Removed the unused anchor. — Sgconlaw (talk) 20:17, 19 September 2023 (UTC)

Hello,

I've visited your website at the following link: https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?oldid=49405675#%D7%A9%D7%95%D7%A3 & have attempted to start a discussion (I have input that has NOT been presented/discussed on the Hebrew root ש-ו-ף) but, the entry seemed to have had a strikethrough (with a message to page visitors that the discussion had been moved elsewhere/archived & WITHOUT ANY option to start a new conversation!). What's up with THAT...? I'd appreciate your early expert advice & look forward to it. AK63 (talk) 11:50, 19 September 2023 (UTC)

@AK63: That's a five-year-old RFV discussion. RFV (Requests for Verification) is a procedure for demonstrating that a term actually exists. It was struck because the person who brought up that particular case was satisfied that the relevant senses exist. You always have an option to start a new conversation, the strikethrough simply indicated that that particular conversation was over. A good place for generic discussions of a particular term might be the Tea Room. —Al-Muqanna المقنع (talk) 12:07, 19 September 2023 (UTC)

Or the Wiktionary:Etymology scriptorium for an etymology discussion of a particular entry. DCDuring (talk) 13:17, 19 September 2023 (UTC)

Thank you / shuqran, for your response, ya AlMuqanna :) AK63 (talk) 09:13, 22 September 2023 (UTC)

The word ‘шайлушай’ is increasingly common and deserves an entry. 216.56.8.2 19:26, 19 September 2023 (UTC)

What language? Benwing2 (talk) 21:10, 20 September 2023 (UTC)

@Benwing2: Russian. It's some kind of popular meme on Tiktok, which I haven't looked at yet. Possibly not a dictionary material. Anatoli T. ^{(обсудить}/^вклад) 05:03, 21 September 2023 (UTC)

According to some russian reddits, it's a pretty large meme. Some users said joke is that the word "Шайлушай" is just gibberish. I guess it's a common enough word but can we even have an entry for humorous gibberish? I've never seen an entry for something like that. سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 23:01, 23 September 2023 (UTC)

@Sameerhameedy It would fall under the "hot word" provision if we included it at all, but I'm skeptical. Generally a word needs to have three cites (uses, not mentions) over at least a one-year period, and "hot words" are included only if we think it's likely they will remain in use for a few years. Memes often come and go quickly. Benwing2 (talk) 00:53, 24 September 2023 (UTC)

For pronunciation modules such as https://en.wiktionary.orghttps://dictious.com/en/Module:bg-pronunciation, how would I run the Lua script on my own computer? I keep getting errors about other modules particularly mw.ustring not being found. 195.194.22.58 10:15, 20 September 2023 (UTC)

There are two possibilities. One is to do a network call and have the Lua code run on the MediaWiki servers. This can be done using site.expand_text() in Pywikibot, e.g. I use site.expand_text("<code style="white-space:pre-wrap">{{]:]|getLanguageData}}</code>") to fetch data on all languages from Module:User:MewBot. The limitation here is MediaWiki only lets you do one call per second (although you can work around that using multiple threads, and you could also write a small module that takes a list of pronunciations, generates them all at once, and returns the results JSON-encoded). The other possibility is to set up a MediaWiki Lua environment on your own computer; this potentially runs a lot faster but requires some setup. I have never done this but I think User:Erutuon and some other editors around here have done so; maybe they can comment. Benwing2 (talk) 21:10, 20 September 2023 (UTC)

At maven, "Terms with manual transliterations different from the automated ones/yi" was showing up as a hidden category, so I removed the manual transliteration. An automated transliteration was displayed, but also "]". — Sgconlaw (talk) 13:21, 20 September 2023 (UTC)

@Sgconlaw You should not have removed the manual translit. Yiddish has a bunch of words imported from Hebrew that use the Hebrew spelling but Yiddish pronunciation and need manual translit. This is one of them, and the resulting transliteration 'mvin' is all wrong. Benwing2 (talk) 21:13, 20 September 2023 (UTC)

The issue with the empty category is something else; I'll take a look. Benwing2 (talk) 21:14, 20 September 2023 (UTC)

@Benwing2: thanks. Mmmm, if a manual transliteration is required, then the template probably shouldn't be displaying "Category:Terms with manual transliterations different from the automated ones/yi"? — Sgconlaw (talk) 04:04, 21 September 2023 (UTC)

@Sgconlaw This category is added whenever there is a manual translit different from the automated one, regardless of whether it's required: there's no way in general to know automatically whether a given manual translit is required or correct. Probably actually the category should be named more like 'Pages with Yiddish manual transliterations different from the automated ones'; the current formatting is nonstandard as well as misleading, because the term with the manual translit often occurs on a different page (e.g. as in this case; maven itself is an English term and has no translit). The description should maybe be updated to make it clearer that pages in this category don't necessarily require cleanup; can you suggest a wording? Benwing2 (talk) 04:17, 21 September 2023 (UTC)

@Benwing2, Sgconlaw: What I was planning to do before the number drastically shrank was to add text to the Pali category files of this nature along the lines of: "The following different manual transliterations are known to be necessary:...", with the list in the category file itself. The category is for maintenance; the pages flagged up need review at some point, but that won't need reviewing very often, especially if the transliteration is stable. It might make sense to instead reference a page of reviews of transliteration, but I'm not sure where to put such a page. Perhaps one could have it as a documentation page sitting under the relevant transliteration module.

Another alternative might be to add a template-level "don't check flag", but exposing it to campaigners and vandals is probably a bad idea. There is a Lua level "don't check flag", which is very useful for SE Asian Thai and Lao Pali inflection tables, where transliteration can need writing system information not available in the one-size fits all interface, and we live dangerously with translation tables on pages at grave risk of running out of memory. --RichardW57m (talk) 13:27, 21 September 2023 (UTC)

@Benwing2: what is the function of categories like "Category:Terms with manual transliterations different from the automated ones/LANG"? Knowing this, I might have a better idea of how they should be named. To me, the current name suggests that the manual transliteration should be removed. — Sgconlaw (talk) 22:19, 21 September 2023 (UTC)

@Sgconlaw We also have categories like Category:Terms with redundant transliterations/yi when there are manual transliterations the same as the automated ones. I think the purpose of the 'different from the automated ones' is for checking whether the manual transliterations are wrong, e.g. they are using a different transliteration system from the automatic one. Unfortunately as User:RichardW57 points out, there's currently no tracking of which ones are necessary, which would have to be specified manually in a list somewhere. Benwing2 (talk) 23:16, 21 September 2023 (UTC)

@Sgconlaw, Benwing2 And the redundant transliterations are tracked with a view to reverting to automatic transliterations, though there can be problems, e.g. when transliteration and Roman script equivalent diverge. (I work on the principle that words in the same language should be transliterated the same if they are spelt and pronounced the same.) --RichardW57 (talk) 07:52, 22 September 2023 (UTC)

@Benwing2: ah, I hadn't realized there were two types of categories, "Terms with manual transliterations different from the automated ones" and "Terms with redundant transliterations". In that case I guess "Terms with manual transliterations different from the automated ones" doesn't need to be renamed, and it's just a matter of only removing transliterations from the "redundant" ones (though I'm not sure how the issue raised by @RichardW57 should be resolved). — Sgconlaw (talk) 13:10, 22 September 2023 (UTC)

@Benwing2, Sgconlaw: For Pali, that problem was resolved as follows:

1. As the 'principal' script is Latin, non-Roman script entries have a definition given by {{pi-sc}}, which displays the Roman script equivalent.
2. Headword scripts don't normally present transliterations, because of the previous point, but they will if given explicitly. A transcription value of '+' is interpreted as 'Give the standard transcription'. As far as I am aware, this convention is only available at the level of Pali headword scripts and module; it does not (yet) descend to Module:links.

With the convention for '+', it was no longer necessary to spell out the transliteration, and so Category:Terms with redundant transliterations/pi was emptied. --RichardW57 (talk) 09:24, 23 September 2023 (UTC)

Here's a few edit requests for the module:

1. Add the 5 new IDS chars ( and ) to the table at Line 22. The implementation might be a bit tricky, espeically for the last one.
2. Replace the third link at Line 88 from Module:Hani-sortkey/serializer to Module:Hani-sortkey/data/serializer
3. Add this clause at Line 142 to allow bypassing the while loop entirely if the text does not contain IDS characters (which is usually the case): if not text:find("") then return text end.

– wpi (talk) 17:03, 20 September 2023 (UTC)

@Wpi I've dealt with this: 5 new characters added, the link's been corrected, and I've restructured how the module iterates over the string so that it does everything in a single loop, and only runs the IDS code if it absolutely needs to. This avoids having to use mw.ustring.find, which is slow and inefficient. Theknightwho (talk) 19:20, 21 September 2023 (UTC)

I could have sworn there was a category for communes in France, but it seems to have been removed. I discussed it with User:Benwing2 earlier this year (User talk:Donnanz). What happened to it? DonnanZ (talk) 18:42, 20 September 2023 (UTC)

Category:fr:Communes in France though it only has one entry anyway. Doesn't look like there was ever an English category for it. —Al-Muqanna المقنع (talk) 18:57, 20 September 2023 (UTC)

Well, I haven't gone mad. I suspect somebody has disabled and deleted it. DonnanZ (talk) 19:57, 20 September 2023 (UTC)

It's "Communes in France" for Senez. The categories for Algeria and Chile are "Communes of ...". Those two are working as they should be. I think it was originally "Communes of France" in English and French. DonnanZ (talk) 23:21, 20 September 2023 (UTC)

Category:en:Communes of France doesn't appear to have been deleted nor ever created. I would add it for you, but apparently I can't edit Module:place/shared-data, even though I can Module:category tree/topic cat/data/Places. @Benwing2 -- Sokkjō 23:46, 20 September 2023 (UTC)

@Sokkjo, Benwing2: It should be created for English and French as so many entries include it. The anomaly of Category:fr:Communes in France (created by Wingerbot on 13 April 2023) needs to be addressed (in vs. of). Category:Municipalities of France also exists, but is hardly used. DonnanZ (talk) 09:09, 21 September 2023 (UTC)

@Benwing2: Can we make it so Module:place/shared-data has the same permisions as Module:category tree/topic cat/data/Places? Sucks to have to ask every time. -- Sokkjō 17:50, 21 September 2023 (UTC)

@Sokkjo: It was User:Erutuon who added the template editor protection. I think the reason is that {{place}} is used on ~ 100,000 pages so any breakage to one of the modules it uses will cause a ton of errors, whereas Module:category tree/topic cat/data/Places is only used on category pages. However, Module:place and Module:place/data weren't protected at all, so I made all three have autoconfirmed protection. This means you should be able to edit them; hopefully we won't run into problems with bad edits from other autoconfirmed users. Benwing2 (talk) 20:29, 21 September 2023 (UTC)

👌-- Sokkjō 20:53, 21 September 2023 (UTC)

We're down to 42 from 64 yesterday. I think this is partly due to the work I did optimizing the labels data modules; I replaced one-element lists with bare items, converted duplicated strings to true wherever possible, and optimized the data module postprocessing step so it avoided doing work at that point in exchange for doing it later, when the label is processed. The idea is that the entire data module gets loaded into memory any time at least one label is used (well, there are several data modules, but we can ignore that for now); but the additional processing done when a label is seen is only done for the labels actually existing on the page, which is only a small subset of the entire set of labels. And using loadData() on a module seems to use a lot of overhead, esp. for tables. So it's better to make the data modules as small as possible and do more work when processing the items actually needed. I think there's even more that can be done, ala using numbered entries instead of named ones for the most common fields, like we do for the language modules. There are also other data modules that could be similarly optimized. User:Theknightwho I think there's some postprocessing now done on the language modules, can we do a similar trick with them? Any other subsystems you can think of that are amenable to similar tricks? Benwing2 (talk) 19:00, 20 September 2023 (UTC)

@Benwing2 Yes, I've come to the same conclusion - it's usually better to do more work if it means you can avoid memory use. The savings were quite modest, but I've just reduced the size of the Module:Hani-sortkey/data/serialized string from 487KB to 301KB on the same principle: previously, every sortkey was stored in a format like 乙04, which took 5 bytes per sortkey. I've converted this to 3 bytes by using the format \00504, where the first byte is between 1 and 214 (since there are 214 radicals). The new method requires converting it to the correct radical once it's been accessed, but that's a pretty trivial process since the radicals are saved elsewhere in the string and can be looked up in a similar fashion once you have the index number. (Note that the page is longer than 301KB, since \005 takes 4 bytes to save, but obviously Lua only sees it as 1 byte). Theknightwho (talk) 20:36, 20 September 2023 (UTC)

Recently the MediaWiki developers added an inline toggle button to control whether the diffs shown when you view the history of a page are rendered in two side-by-side windows or in one inline window. In general I much prefer inline diffs, but the current formatting of the inline diffs is shitty in that it doesn't show the line numbers (unlike the side-by-side view), and doesn't make it clear where the hunks begin and end. Does anyone know if there is a way of customizing this? Benwing2 (talk) 23:05, 20 September 2023 (UTC)

The lack of hunks is reported at phab:T346460. As for the line numbers, I've never found them remotely useful, except for code files (modules etc). Would you want them visible everywhere or just on code pages? I could file another Phabricator task - it's not something that could be locally customized. This, that and the other (talk) 23:35, 20 September 2023 (UTC)

@This, that and the other Thanks. For line numbers, just on code pages, I don't care whether there are line numbers on discussion pages and mainspace pages as I'm unlikely to look at them. Benwing2 (talk) 02:16, 21 September 2023 (UTC)

Filed phab:T347013. This, that and the other (talk) 09:11, 21 September 2023 (UTC)

@This, that and the other: Thank you! Benwing2 (talk) 20:22, 21 September 2023 (UTC)

@Benwing I believe this is now added, although I don't think my contribution had a whole lot to do with it. This, that and the other (talk) 06:18, 14 October 2023 (UTC)

@This, that and the other Yup, I see it in inline diff mode. Now I can finally turn on inline diffs :) ... Benwing2 (talk) 06:45, 14 October 2023 (UTC)

After a discussion on Discord I came up with the idea of moving languages and scripts from MediaWiki:Common.css to a gadget at MediaWiki:Gadget-LanguagesAndScripts.css. That makes it apply on mobile for the first time, and it can be disabled by logged-in users in preferences. I'm not sure if mobile devices usually have enough fonts installed for this to actually be beneficial.

It is 17 kilobytes long when minified, and is delivered in the head tag of the page, so it makes up a large fraction of the total HTML size of a small entry (~60 KB non-minified). It also adds a lot of style rules for a mobile browser to apply. I don't know if this is going to be a problem for underpowered cell phones, but if so, we could disable it for the mobile skin in MediaWiki:Gadgets-definition. — Eru·tuon 03:49, 21 September 2023 (UTC)

Great initiative! This will reduce duplication with MediaWiki:Mobile.css, from which I suppose these can now be removed @Erutuon? This, that and the other (talk) 09:56, 21 September 2023 (UTC)

@This, that and the other: Yep, I've just done that. — Eru·tuon 21:19, 21 September 2023 (UTC)

Hello
I've recently created the Sassarese pronunciation template {{sdc-IPA}}, but when I try to use it, I get the error message in the title: Lua error: Unmatched close-paren at pattern character 48.
Now, I counted the parentheses, and there is an equal number of ( and ), an equal number of , and an equal number of { and }.
Can someone please explain the nature of this error to me? —— GianWiki (talk) 11:39, 22 September 2023 (UTC)

@GianWiki: It looks like fair punishment for using a long template call rather than a Lua module. If you'd made a Lua Module, you'd've got a line number. As the error lies in one of the parameters, just try each substitution parameter on its own until you find the error - or do a binary search if you can. At the moment, all you know is that the problem is detected at character 48 of one of your parameters.

Incidentally, the subexpression looks very odd. What do you think it means? Whatever it is, it ought to be extracted as an element, something one can do in Lua but not in templates. You may have a problem with the regular expression engine. You may have to first change the sequence 'sg' to a single character (e.g. to Ⓖ) to do the replacements you want. --RichardW57m (talk) 13:20, 22 September 2023 (UTC)

@GianWiki I would really, really strongly advise that you don't take this approach. We generally don't like having imported modules from Wikipedia, because they're often not very good and difficult to maintain. In this case, it's made debugging your issues really hard, because it tells you nothing of value.

Would you be willing to redo things in a proper Lua module? That's generally how we do things here, and it makes things much easier to deal with. Theknightwho (talk) 13:38, 22 September 2023 (UTC)

@Theknightwho I really would be (actually, that was my first thought), except I know basically nothing about Lua, and it seems fairly complicated to me (as in, there are a lot of things to learn between me and the things I needed to make the template). To be honest, I thought I could circumvent this problem through that module, but it didn't pan out. I thought I could kinda lazy my way out of learning Lua. Thank you very much for the heads-up, by the way. —— GianWiki (talk) 14:53, 22 September 2023 (UTC)

@GianWiki I completely agree with User:Theknightwho about Wikipedia modules; this MultiReplace module is used on about 20 mostly reference pages so it shouldn't be too hard to eliminate. Benwing2 (talk) 21:17, 23 September 2023 (UTC)

@GianWiki Just BTW, I completely agree with User:Theknightwho about the general undesirability of importing Wikipedia modules. Benwing2 (talk) 01:56, 24 September 2023 (UTC)

Thank you for informing me about this. I had no idea. —— GianWiki (talk) 06:41, 24 September 2023 (UTC)

@Gianwiki: The pair of parameters where things go wrong may be displayed in a sandbox as

:: {{#invoke:MultiReplace|main|Elephant<!-- :: -->|(gli)à)(l)(m)(n)(pp)(r)(s)(tt)(vv)]?|a<!-- ::-->}} ::

The closing parenthesis complained of is at the 48th character of the long parameter, immediately after . I suggest you study the pattern definition at https://www.mediawiki.orghttps://dictious.com/en/Extension:Scribunto/Lua_reference_manual#Patterns. Your 'pattern' is composed of:

1. Capture group (gli). It is delimited by parentheses. It does not denote a context, as I think you think.
2. One-character Regular Expression (RE) "à".
3. One-character RE "" Parentheses and left square brackets (", i.e. match one of 'b', 'c', 'd', 'f', 'g', 'l', 'n', 'i', 'j', '[', '(' and ')', which I am sure is not what you intended.
4. One-character RE
5. ')', the right parenthesis not matching the syntax at character 48.
6. ...

The type of substitution you would have in Lua, if your scheme is basically correct, would look something like

text = gsub(text, "(gli)à(...)", "%1a%2") where the ellipsis is some complicated expression that I think would have to rely on previous substitutions to make it simple enough to express in Lua regular expressions. --RichardW57m (talk) 14:13, 22 September 2023 (UTC)

@RichardW57m Thank you very much for the useful info. I'll have to take a better look into this. —— GianWiki (talk) 19:22, 24 September 2023 (UTC)

@GianWiki:

The tl;dr version is that parentheses and '. --RichardW57m (talk) 14:36, 22 September 2023 (UTC)

A lot of templates allow alt (e.g. {{prefix}}, {{syn}}, {{desc}}) whereas {{link}} and {{mention}} currently don't, although the 2 parameter does the same. Could we add alt to {{link}} and {{mention}} to make things more consistent? tbm (talk) 03:57, 23 September 2023 (UTC)

@Tbm Generally, the templates supporting |alt= are those that take multiple terms, including all those you have mentioned, while those that take only one term have the display form (the equivalent of |alt=) in the parameter after the term. Sometimes the second type of templates support |alt=, but it hasn't been a priority to add it everywhere because it's longer (and generally you can also use a two-part link in the term parameter). Benwing2 (talk) 21:06, 23 September 2023 (UTC)

So Punjabi, Saraiki etc. are using the Persian font for numbers instead of the Urdu one Compare Module:number list/data/pnb (Punjabi), Module:number list/data/skr (Saraiki) and Module:number list/data/ur (Urdu) Notevenkidding (talk) 06:47, 23 September 2023 (UTC)

This is part of a larger issue of forcing specific fonts for specific languages. There is a similar but different issue happening to Kazakh and Kyrgyz. Somehow Urdu, Arabic, Uyghur, and Persian are able to force a specific font but other languages can't. I brought up this issue in the discord but it seemed like almost everyone was surprised that some languages had the ability to force a specific font. So the amount of people who would know how to fix font issues are probably small. I suspect This module is the suspect though, but I have no way of confirming that. سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 03:28, 24 September 2023 (UTC)

@Theknightwho do you think if we added code "pnb" and "skr" to Urdus font family, and "kk-Arab" and "Arab" to Uyghurs, that would solve the font issues? Or do you think it's something else? Also @Benwing2, whenever you aren't busy, could you take a look at this too? سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 03:36, 24 September 2023 (UTC)

@Sameerhameedy Apologies, you left me a message earlier that I didn't respond to. You are correct about the module in question, which was recently split out from MediaWiki:Common.css; this specifies the fonts used for each script. See lines 216-268. I notice that Kyrgyz does not have its own script code (see CAT:Kyrgyz language, where the script is just 'Arab'), where Kazakh does (see CAT:Kazakh language, where the script is 'kk-Arab'). There also appears to be some duplication in the font specs, as the first clause in the above lines sets the fonts and then later clauses also set the fonts for specific languages. Also, the gadget CSS file in question was only created a couple of days ago in order to fix mobile font issues, and 'Noto Naskh Arabic' is the first font listed for both 'Arab' and 'kk-Arab', so maybe it is fixed now. Also what do you mean by adding 'pnb' and 'skr' to Urdu's font family? I'm not sure what these are. Beyond this, I'm not sure as CSS isn't really my forte; the right people to look into this are User:Erutuon and/or User:This, that and the other. Benwing2 (talk) 04:05, 24 September 2023 (UTC)

OK, I see 'pnb' is Western Panjabi and 'skr' is Saraiki. Note however, that Western Panjabi has been merged into Punjabi, so the pnb code won't be seen at the CSS level. Also I'm still not sure what you mean about adding language codes to Urdu's font family. Benwing2 (talk) 04:09, 24 September 2023 (UTC)

@Benwing2 sorry, to clarify I was saying that for the section /* Kurdish, Punjabi Shahmukhi, Urdu */ I think the text should possibly be changed to:"

.ku-Arab,

.pa-Arab,

.Arab,

.Arab,

.ur-Arab {

font-family: 'Noto Nastaliq Urdu', Tahoma, 'Arial Unicode MS', 'UT Cairo', 'UT Naskh', sans-serif;}.

Kazakh and Kyrgyz Arabic still don't look correct to me. Looking at Erutuons test cases only the "languages" kk-Arab and ky-Arab force Naskh, the languages "kk" and "ky" use my default system font which doesn't support many characters in those languages. Perhaps the section for Uyghur should add ".kk-Arab, .Arab, .Arab"?

also @Erutuon, sorry to pile so much on you at once. When I turn on your gadget it doesn't force the naskh font in the title when viewed on mobile anymore, but before it did. سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 04:45, 24 September 2023 (UTC)

@Sameerhameedy Not sure what .Arab will do. Since Kazakh already has kk-Arab but not Arab as its script code, the script detection code will detect Arabic-script Kazakh terms as belonging to kk-Arab and do script tagging accordingly. Any Kazakh-specific changes should be done to kk-Arab. If we need to customize for Kyrgyz, presumably we should add a ky-Arab script code like for the other languages, and use it in the CSS. Benwing2 (talk) 05:03, 24 September 2023 (UTC)

@Benwing2 I thought that might've fixed Kazakh not showing in the right font for me but i'm not sure. Users on discord said the fonts were appearing weird for them on mobile, perhaps there's a separate module for mobile? I'm not sure. But Ill shut up and let @Erutuon and @This, that and the other look into it since they actually know CSS. سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 17:29, 24 September 2023 (UTC)

For me پَہلا in Module:number list/data/pnb has the fonts for .pa-Arab, which currently are the same as for Urdu

.ku-Arab, .pa-Arab, .ur-Arab {
	font-family: Tahoma,'Arial Unicode MS','UT Cairo','UT Naskh',sans-serif;
}

(MediaWiki:Gadget-LanguagesAndScripts.css) so I don't see how the CSS could be making it use Persian fonts (search for .fa-Arab on that page).

@Sameerhameedy: My testcases don't test how Kazakh or Kyrgyz text is actually formatted on English Wiktionary. Please just ignore them and look at actual entries. The -Arab-suffixed language tags are web-standard language tagging that is not used on Wiktionary. Please give an example of where you would like Naskh script to be forced.

I can add Noto Nastaliq Urdu to Urdu fonts. — Eru·tuon 19:26, 24 September 2023 (UTC)

@Erutuon Hi the Punjabi and Saraiki number lists are fixed for me now. As for the Kazakh and Kyrgyz thing, the arabic text shown at Айжан shows my system font, instead of Noto Naskh Arabic. Same thing can be seen in KK and KY Arabic-script entries such as جڭگ. (As I mentioned before, Noto Naskh Arabic would be preferable due to NNAs wide support and the rare characters used by Kazakh and Kyrgyz). سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 19:41, 24 September 2023 (UTC)

@Sameerhameedy: Do you have the LanguagesAndScripts gadget enabled in your preferences? If you have it enabled (it should be, because it's enabled by default), the style rule applying to the text in Айжан should select one of the fonts 'Noto Naskh Arabic','Iranian Sans','Segoe UI',Tahoma,'Microsoft Sans Serif','Arial Unicode MS'. — Eru·tuon 19:46, 24 September 2023 (UTC)

@Erutuon, yes I have the setting on and I have Noto Naskh Arabic. Text inputted to {{l|ar}} correctly force Naskh for me, but text entered in {{l|ky}} or {{l|kk}} do not. سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 19:58, 24 September 2023 (UTC)

Very strange! The only reason I can think of is that some style rule is taking precedence over the one I posted, but I have no idea what style rule that would be. The only way to figure out is, if you're on a computer, right-clicking on the offending text without the link here (ايجان), choose "Inspect", look for style rules containing font-family declarations, and find the first style rule that contains a font-family declaration that isn't crossed out. If you can post the style rule (i.e. including the selectors like .Arab in this case), that would give me a clue of what's happening. Maybe there's no style rule overruling the Naskh font and instead the browser is thinking that some other font is more appropriate for lang="ky" text (maybe based on the assumption that Kyrgyz is usually in Cyrillic in Kyrgyzstan). — Eru·tuon 21:44, 24 September 2023 (UTC)

@Erutuon The only thing I see when inspecting from my MacBook is "font-family: 'Linux Libertine','Georgia','Times',serif;" later on in the text it says font-family: sans-serif;

However I when I visited the mobile site on my MacBook (with the mobile user agent) and inspected, it said "font-family: -apple-system,'BlinkMacSystemFont','Segoe UI','Roboto','Inter','Helvetica','Arial',sans-serif;". Im not sure how to read this, but I think the mobile site is prioritizing the system font but the desktop site is forcing the correct fonts.

I think that's the case as when I compare the fonts on my phone and on my computer, the fonts are all displaying correctly on my computer. سَمِیر | Sameer (^{مشارکت‌ها} • ^{کتی من گپ بزن}) 23:45, 25 September 2023 (UTC)

@Sameerhameedy: I wonder if there's some useful info here: This is related to the font setting under "User profile -> Internationalization -> More language settings -> Fonts -> Download fonts when needed" (this is unchecked for me). Benwing2 (talk) 03:12, 1 October 2023 (UTC)

Should {{rfv-quote|topic=xxx}} be placing anything in said category? If so, could someone please create it, as {{auto cat}} doesn't do it. If not, please amend {{rfv-quote}} so as not to place pages in the category and update its documentation so that it tells the truth.

I am re-using dictionary references where I believe @Octahedron80 has misinterpreted pronunciations in Thai script as words. He used it as support for the pronunciations interpreted in words; I am now trying to use it to support the Mon-script words. Someone needs to check the contents of the dictionary; my attempt to buy a copy resulted in us being temporarily scammed of the asking price. The nearest library copy to me is the other side of the Atlantic.--RichardW57 (talk) 13:33, 23 September 2023 (UTC)

The |topic= parameter has been removed from all the RFV/RFD family of templates. Apparently this template was missed, which I have now rectified. The discussion was at Category talk:Entries needing topical attention. This, that and the other (talk) 09:07, 24 September 2023 (UTC)

Thank you for cleaning up. --RichardW57 (talk) 21:35, 25 September 2023 (UTC)

What's the dictionary you are trying to obtain? - -sche (discuss) 01:24, 25 September 2023 (UTC)

This one: พวน รามัญวงศ์ (2005) พจนานุกรมมอญ-ไทย ฉบับมอญสยาม , กรุงเทพฯ : มติชน , →ISBN --RichardW57 (talk) RichardW57 (talk) 21:18, 25 September 2023 (UTC)

There is an awkward situation with the etymology. Would it be possible to add something like {{{pos}}} and/or {{{t}}} and the like? Vininn126 (talk) 15:09, 27 September 2023 (UTC)

Another such case would be dzięki. @Benwing2 do you think you could add another parameter or many to {{sl}}? Vininn126 (talk) 20:15, 28 September 2023 (UTC)

@Vininn126 {{sl}} already has |pos= and |t= params. Can you clarify what params you'd like to have added? Benwing2 (talk) 22:30, 28 September 2023 (UTC)

@Benwing2 when I add that, it mentions the pos of the loaned term. I would like to be able to mention what pos is referred to on the donor language. Please see the linked terms and check for yourself. Vininn126 (talk) 22:43, 28 September 2023 (UTC)

@Vininn126 I did take a look before but I'm still confused as to what your desired outcome is. Can you give an example of how you want it to look? Benwing2 (talk) 23:04, 28 September 2023 (UTC)

I think the issue is that I didn't add the |senseid= param and I don't quite understand how it works. Why does it display "sense 1"? That seems weird. Benwing2 (talk) 23:06, 28 September 2023 (UTC)

@Benwing2 Sorry, this is also an issue with {{senseno}}. I have an issue where I have things like "sense 1" in these defs and it's unclear sense one of WHICH part of speech and I'm not sure how to differentiate between them. I would like the ability to link to specific defs but not rely solely on the text printed by {{senseno}}.

It displays based on the number given at the front of the definition - I requested this feature be added to {{sl}} because it is a type of loaning based, by definition, on senses.

So I guess the issue is more with {{senseno}}. Vininn126 (talk) 06:33, 29 September 2023 (UTC)

Module:zlw-ocs-verb is breaking page width. See býti. @Zhnka, Benwing2. -- Sokkjō 21:20, 27 September 2023 (UTC)

Thank you for bringing this up. I had been ignoring it for a long time having actually no idea how easily it could be repaired. From now on, it shouldn't break the page anymore. Zhnka (talk) 04:20, 28 September 2023 (UTC)

@Sokkjo I happened to notice this but I didn't receive your ping. Did you add the ping afterwards? In general the ping has to be in the same commit as your signature for it to work. Benwing2 (talk) 05:24, 28 September 2023 (UTC)

I see you did do this. When you want to modify a ping, you need to instead re-ping in a new commit with a new signature. Benwing2 (talk) 05:25, 28 September 2023 (UTC)

Yeah, I didn't expect it to ping you, but I figured I'd address it to you as well and you read this page frequently enough. -- Sokkjō 05:28, 28 September 2023 (UTC)

Thanks. -- Sokkjō 05:28, 28 September 2023 (UTC)

The template {{t}} (and thus also related templates like {{l}} and {{m}}) is incorrectly stripping diacriticals from Vilamovian entries. Thus, {{t|wym|łȧjst|f}} produces "łȧjst f", even though there is an entry for łȧjst. — Sgconlaw (talk) 22:27, 27 September 2023 (UTC)

@Sgconlaw: This is being done in the languages module, and likely intentionally. I don't know anything about Vilamovian but Wikipedia (which calls it the Wymysorys language) doesn't list ȧ in the Vilamovian alphabet, so I suspect it's not used in normal spelling. What does ȧ mean? Benwing2 (talk) 05:22, 28 September 2023 (UTC)

@Benwing2: oh, I'm afraid have no clue. I just noticed that the Vilamovian word kept showing up as a red link when adding it as a translated word. (Pinging @Spl908455 who created the entry, though the last time they contributed was in September 2022.) — Sgconlaw (talk) 11:30, 28 September 2023 (UTC)

@Sgconlaw This page on Omniglot says that ȧ is one of the "other letters" (not in the "alphabet" per se) and pronounced (whereas regular a is pronounced ; but the digraph ao is also pronounced ). I don't know what "other letters" means here. Benwing2 (talk) 20:03, 28 September 2023 (UTC)

BTW maybe we just need to move łȧjst to łajst and add a |head= parameter that includes the ȧ. Benwing2 (talk) 20:04, 28 September 2023 (UTC)

@Benwing2: I guess it depends on whether the word is always spelled with an ȧ or whether that is just a typographical variant. — Sgconlaw (talk) 20:34, 28 September 2023 (UTC)

I hope it's ok to bring this up again here because there was no action at the talk page for almost 2 months. Ancient Greek Module:grc-decl is generating tables with oversized initial column (see ὁ for example) which are almost running off the edge of my screen, even at 90% zoom, forcing the final elements to be awkwardly compressed. It seems to me that this first column in particular (containing Number, Case/Gender, etc.) could comfortably be specified at half or even one third of its current width. Also contributing to this problem is the variant width of the following columns—which I can only assume is set based on the respective widths of the headings Masculine, Feminine, Neuter. Would it also be possible to get more uniform sizing of the columns (given that the length of each form is fairly uniform, at least within each given number) across the table. Masculine in particular seems to be far wider than necessary. Cheers. Helrasincke (talk) 15:00, 29 September 2023 (UTC)

@Helrasincke Yes, the structure of this template is a mess. I'm reluctant to make any quick changes because it looks like they would affect all Ancient Greek declension tables, even one-column ones like at ἡμεῖς (hēmeîs), which clearly don't need to span the entire width of the page and really need a deeper fix :( This, that and the other (talk) 12:19, 1 October 2023 (UTC)

@This, that and the other: MediaWiki:Vector-2022.css and MediaWiki:Vector-2022.js are now in CAT:E. I can't remember the last time that happened. Chuck Entz (talk) 01:14, 2 October 2023 (UTC)

@Chuck Entz thanks, fixed. It was my use of {{auto cat}} in a comment - I have no idea why MediaWiki tries to parse that... This, that and the other (talk) 03:24, 2 October 2023 (UTC)

The template does not play nice with images and sister-project boxes, overlapping template text content with images and sister-project boxes. I have moved the sister-project boxes. DCDuring (talk) 15:33, 29 September 2023 (UTC)

Apparently, the "problem" only occurs in the preview. Probably not worth addressing. DCDuring (talk) 15:37, 29 September 2023 (UTC)

Problem does not occur only in preview. It occurs at some pagewidths, when the page is newly loaded, but disappears when window size is changed and does not seem to recur, even at window sizes close to the original one. If this occurs with other column templates, it might well be worth addressing. DCDuring (talk) 16:07, 29 September 2023 (UTC)

I've just come across a quote attributed to a wrong source at gang#Etymology_4 which I suspect may be a result of a bot run or bot assisted clean-up of unformatted quotes. I've fixed it now, but this potentially affects much more than a single entry. I'm unable to track when exactly the text was deleted (I assume the page history is too big for the little tool), but compare here (addition of 2 unformatted quotes under Etymology 4) and here (the two have been mashed together). If somebody with superior technical skills could look into this, that'd be awesome. Helrasincke (talk) 17:02, 29 September 2023 (UTC)

@Helrasincke: The quotes were added in this 2015 edit (the deletion of the {{checktrans-bottom}} template since then means you have to look in the "Translations to be checked" box to see it) with the quote before the attribution. In this 2016 edit, the text of the first quote was mistaken for a usage example and removed, while its attribution was assumed to belong to the second quote and everything after the text of the second quote was also removed. This was human error- no bot was involved at the time. Chuck Entz (talk) 18:41, 29 September 2023 (UTC)

@Chuck Entz Ok good to know, thanks for looking into it. Helrasincke (talk) 19:32, 29 September 2023 (UTC)

This user auto-creates categories like CAT:User bxr-3. Per the talk page of this user, to disable the category creation we need to file a Phabricator bug report. I am going to do that for the following reasons:

1. I have put these categories under the {{auto cat}} system, whereas the bot behind the user adds manual text that clashes with the text generated by {{auto cat}}.
2. It sometimes generates categories for nonexistent language codes (as in 'bxr' above; we have a 'bua' code for Buryat; 'bxr' is an ISO 639-3 code for 'Russia Buryat').

If you have concerns please let me know. Benwing2 (talk) 23:28, 29 September 2023 (UTC)

If we have better 'bot infrastructure' for (semi-)automatically creating 'wanted' Babel categories these days, then yeah, this could be turned off—or maybe just blocked? (You'll notice it was blocked a couple times over a decade ago, but then unblocked since back then it was a necessary evil, since it mostly created valid categories which were not otherwise going to be created, although it has always also created annoyingly wrong categories too.) - -sche (discuss) 00:48, 30 September 2023 (UTC)

@-sche That's a good idea, I will block it. With the new code I've written, these user-competency categories can be auto-created with {{auto cat}} as long as the code in question is a valid full or etymology-only language, and params are available to specify the native-language translation of the English text (if you don't specify such a param, it gets added to a request category except for English and subcodes like 'en-GB'). AFAIK there are about 500 uncreated user-competency categories in Special:WantedCategories, which will get auto-created next time I run my script to create {{auto cat}}-able categories in Special:WantedCategories. Benwing2 (talk) 01:13, 30 September 2023 (UTC)

Read this in your language • Please help translate to your language • Please tell other users about these changes

In 2024, editors who have not registered an account will automatically begin using temporary accounts. These editors are sometimes called "IP editors" because the IP address is displayed in the page history.

The Trust and Safety Product team gave a presentation at Wikimania about this change. You can watch it on YouTube.

There is more information at m:IP Editing: Privacy Enhancement and Abuse Mitigation.

SGrabarczuk (WMF) (talk) 02:05, 30 September 2023 (UTC)

There's been a lot of teeth-gnashing on Wikipedia about how the fact that the system lets people request a new temporary ID as often as they like makes it harder to track that just one person is making a series of POV or vandalistic edits, although it is not clear to me if this actually represents a significant change relative to the existing option to make multiple named accounts. pt.Wikipedia banned unregistered / IP editors entirely a few years ago, which I guess we could always fall back on as a last resort if this turns out to be as much of a problem as pessimists think... - -sche (discuss) 02:35, 30 September 2023 (UTC)

"However, we will continue to give access to users who need to see them in order to protect the wikis." So potentially not a big deal. "Users who need them" includes admins but also other trusted users, I believe. See also m:IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/FAQ#I_have_a_qualified_account._How_can_I_see_the_IP_addresses?. This, that and the other (talk) 07:17, 30 September 2023 (UTC)

"pt.Wikipedia banned unregistered / IP editors entirely a few years ago, which I guess we could always fall back on as a last resort if this turns out to be as much of a problem as pessimists think..."

I like the temporary ID change, but doing it like Portuguese Wikipedia? Please don't. It's seriously inconvenient; I can't tell you how many times I encountered typos or places I could add a line here or there in pt.Wikipedia and then gave up fixing it because it wouldn't let me publish it. I feel like logging in can be a bit of chore (especially on mobile) and sometimes PC I get logged out randomly...

If that change got implemented, I'd probably just stop editing here altogether like I did over there. I'm not sure if I'm the only one, but I kinda doubt it? Still thought it'd be nice to give my 2 cents.

...Come to think of it, I'm not sure if I'm logged in right now. I'm User:MedK1. 2804:1B0:1901:CA73:4C8:C9CA:DDE4:8B93 09:26, 6 October 2023 (UTC)