Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Andyross (talk | contribs) at 17:13, 20 December 2021 (→‎No horizontal scrollbar on wide tables). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.


Make dark mode toggle script a gadget?

There appears to be a quite a bit of interest in dark mode - going by the several help desk and teahouse queries and the posts at user talk:Volker E. (WMF)/dark-mode. However, the current user experience is sub-optimal as the gadget doesn't provide a toggle, and it seems unlikely that users want the dark mode on all the time. So I suggest converting a dark-mode toggling script such as User:SD0001/dark-mode-toggle.js into a gadget. See also the initial discussion. – SD0001 (talk) 06:37, 26 November 2021 (UTC)[reply]

Not a direct answer to your suggestion, but I recently created Wikipedia:Dark mode to try to consolidate info on various dark modes available in one place. This page could also be a good place to discuss a toggle which has come up a few times.Dialectric (talk) 10:14, 26 November 2021 (UTC)[reply]
Posted a linkback to here on its talk page. – SD0001 (talk) 05:47, 28 November 2021 (UTC)[reply]
  • Support I didn't use the dark mode because it didn't have a toggle, and I didn't use SD0001's toggle because it didn't support toggling it without reloading the page, but now that it does, this seems like a good idea. Nardog (talk) 07:42, 28 November 2021 (UTC)[reply]
  • Support I did it on viwiki. P.T.Đ (talk) 18:27, 29 November 2021 (UTC)[reply]
  • Support. Would be very useful. MichaelMaggs (talk) 08:31, 30 November 2021 (UTC)[reply]
  • Support. Sure I can see the value in this one. Ktin (talk) 21:29, 1 December 2021 (UTC)[reply]
  • Support I think this is a great idea if you want to read or edit Wikipedia at night or you have sensitive eyes. I think adding a built-in high-contrast mode too would also be useful for visually impaired Wikipedians. Linux rules, Windows drools (talk) 06:48, 3 December 2021 (UTC)[reply]
  • Question... any Foundation/phab/MediaWiki movement on this lately? If they're doing something about it soon then we might want to let that option take its course. Enterprisey (talk!) 07:23, 3 December 2021 (UTC)[reply]
    Not as far as I know. @MusikAnimal would be able to provide a qualified answer. Dark mode did end up #2 in 2019 Community Wishlist but it was declined. – SD0001 (talk) 13:21, 3 December 2021 (UTC)[reply]
    ughhhhhhhhh ok, thanks for the digging. Support as it's the best option we have available; I'll stand by to implement it, assuming there's consensus here (I see a little precipitation, in fact). I was going to make a few feature requests for the script but it already implemented everything I could think of, so great job! Enterprisey (talk!) 20:20, 3 December 2021 (UTC)[reply]
    To my knowledge, no, there is no official dark mode coming soon. What I had heard in the past was that it was (maybe) going to be part of the Desktop Improvements project, so you could ask over on their talk page.
    Anyway, given the absence of a better system, I too support making the toggle script a gadget. I wish there was a way to have both gadgets in the same definition, though, so the user only has to tick one checkbox in their gadget preferences. I suppose that isn't possible? Additionally, I think the Dark Mode gadget should graduate from the "Testing and development" section. It has remained there as we kinked out the bugs, which I assume is more stable now. It hurts to see us iterate and improve on the gadget while mw:Extension:DarkMode collects dust, but I digress. — MusikAnimal talk 20:01, 6 December 2021 (UTC)[reply]
    In the sense of possibility, yes; in the sense of good possibility? it goes from being a styles-only (early) load to a late load, so FOUCs for everyone. Izno (talk) 21:05, 6 December 2021 (UTC)[reply]
    If I understood the conversation between SD0001 and you correctly at Wikipedia:Village pump (technical)/Archive 189 § Proposal for a dark-mode gadget addition (before Earth Day 22 April?), it seems it should be possible to just enable the toggle gadget. isaacl (talk) 21:15, 6 December 2021 (UTC)[reply]
    Ah right, apologies for my poor memory and negligence to re-read the discussion! So it seems we will have to have two visible checkboxes, but the user needs only to enable the toggle gadget. That said, perhaps it's best to keep the core Dark Mode gadget where it is under "Testing and development", since it will only be for internal use. Re Izno on FOUCs: my understanding is there won't be any visual flickering, but with the caveat that Dark Mode itself won't enable until you browse to a different page. I think that's fine, though, as long as it's clear in the documentation.
    SD0001 Any interest in making the toggle in the personal toolbar like User:Volker E. (WMF)/dark-mode and the DarkMode extension, or should we keep it nested under #p-cactions ("More" menu)? No strong feelings from me, but I would think the personal toolbar will more clearly expose the toggle, and be less clutter for those of us with many things already buried in cactions. — MusikAnimal talk 22:11, 6 December 2021 (UTC)[reply]
    @MusikAnimal The caveat has also been removed now (see talk discussion). Toggling applies the new mode immediately by modifying the <link> tag on the page -- which is hacky from a developer perspective but I think worth it given the aesthetic effect from a user perspective. Re the extension: actually I thought about suggesting the same technique for it as you can then avoid sending the dark mode styles to the client when dark mode is disabled - but was unsure if the hack would survive an MW code review!
    Re portlet location: no strong feelings from me as well, but I thought it was better in cactions as that's the standard place for script/gadget buttons, and there's no jump effect (which could be avoided by reserving space using the css, but then there could be folks using just dark-mode without the toggle gadget) – SD0001 (talk) 16:50, 8 December 2021 (UTC)[reply]
    I would prefer p-personal too, it's annoying it gets collapsed in "More" with p-cactions in Vector. Nardog (talk) 23:23, 8 December 2021 (UTC)[reply]
    I'm gonna come down on the side of p-personal as well because this gadget is going to be used by new users, so the change to the interface should be obvious. Of course, nothing against a common.js "preference" (the horror!) to set it to p-cactions or whatever. Enterprisey (talk!) 08:56, 9 December 2021 (UTC)[reply]
    Looks like I stand outnumbered. Feel free to make the change (before or after this becomes a gadget). It isn't exactly trivial however as it needs accompanying CSS to avoid the jump effect and we need to support minerva as well (in which order of elements in p-personal is different). – SD0001 (talk) 08:00, 14 December 2021 (UTC)[reply]
    pt-preferences doesn't seem to exist unless advanced mode is on. Edit request filed. Nardog (talk) 11:01, 16 December 2021 (UTC)[reply]
  • Support as a user of the gadget first, then swapping to the toggle because the dark mode handled certain tools like Redwarn terribly. Super good for proofreading and resting my weary eyes when I end up editing at 2 in the morning. Sennecaster (Chat) 19:06, 6 December 2021 (UTC)[reply]
  • Support - I can't really understand why dark mode isn't a thing here ?, It's like the WMF still think we're in 1996 or something. Anyway I support this proposal. –Davey2010Talk 22:00, 7 December 2021 (UTC)[reply]
  • Support: My eyes would really appreciate a dark mode right now. I've been dealing vertigo today and yesterday due to COVID—more specifically, due to fluid buildup causing pressure in my inner ears—and Wikipedia, one of my homepage tabs, along with YouTube and Facebook, is the only one without a dark mode. Sunglasses have been helping today. However, I also prefer dark styles in general and would still support it even if I weren't currently sick. Amaury • 02:44, 8 December 2021 (UTC)[reply]
    @Amaury and Davey2010: You have access to a dark mode today, please take a look in gadgets preferences toward the bottom. This discussion is solely about being able to toggle easily between dark and light. Izno (talk) 02:54, 8 December 2021 (UTC)[reply]
    @Izno: Doesn't look like it affects the Preferences page itself, but that's fine. There's not ever a reason for me to go to that page except rarely when I change something like just now. I wish I had known about this all this time. Wow! Thanks! Amaury • 02:58, 8 December 2021 (UTC)[reply]
    No gadget ever affects the preferences page. That's for safety reasons. —TheDJ (talk • contribs) 23:32, 8 December 2021 (UTC)[reply]
    Like I said, it's not a big deal for me, but what safety reasons? Amaury • 23:47, 8 December 2021 (UTC)[reply]
    You don't want to make it impossible to disable a gadget that is causing trouble when enabled. --Redrose64 🌹 (talk) 23:54, 8 December 2021 (UTC)[reply]
    @Izno Brilliant thank you, I'll admit I never ever expected it to be in gadgets but gadgets is better than nothing at all, My eyes and I are very pleased lol, Thanks, –Davey2010Talk 08:45, 8 December 2021 (UTC)[reply]
  • Support: Cabayi (talk) 09:11, 9 December 2021 (UTC)[reply]
  • Support a toggle seems useful. Dreamy Jazz talk to me | my contributions 11:37, 9 December 2021 (UTC)[reply]
  • Support: It's been some months now we have it as a gadget in my homewiki (SqWiki). - Klein Muçi (talk) 09:50, 11 December 2021 (UTC)[reply]
  • Requested implementation at: Wikipedia:Interface administrators' noticeboard#Dark mode toggle gadget. – SD0001 (talk) 10:11, 14 December 2021 (UTC)[reply]
Support and make it a default enabled gadget - for our readers sake, everything has a dark mode. We should provide one by default. ✨ Ed talk! ✨ 10:32, 15 December 2021 (UTC)[reply]

pass table or struct to Lua module?

Is it possible to pass a table via invoke?

A currently used template has an interface width of about 100 parameters and still is not able to show up neatly what it's supposed to. So I'd like to write a module accepting a table of uncertain length, returning table rows for insertion into WP table:

  • Each input element shall consist of an n-type and a content.
    • the whole output shall be ordered by n-type.
    • display of content depends on n-type.
  • Each content shall consist of an uncertain number of parts.
    • Each part is an n-value, a description, or an n-value AND a description and optionally has one or more control params.

So in Lua such a structure should be declarable like this: 

input = {
  {n-type="first",
   content={{n-value="Harry", description="H.r."}}},
  {n-type="throne",
   content={{n-value="Henry I.", crown=true},
            {description="H.nr. 1st, Boss of Foo and Bar"},
            {n-value="Big Baboo", description="unofficial"}}}
}

How could I pass such a structure in WP via invoke to my module? --Vollbracht (talk) 04:07, 12 December 2021 (UTC)[reply]

I don't think that you can. {{#invoke:}}, accepts positional or named parameters as text strings. It is possible to pass Lua tables from one module to another but not from wikitext into a module.
Just a quibble: n-type and n-value keys in your example should be written: ['n-type'] and ['n-value'] because otherwise Lua will attempt to perform a subtraction and because type is reserved as a standard library function name.
—Trappist the monk (talk) 13:11, 12 December 2021 (UTC)[reply]
Thank you so far! Anyway I won't call my params that way in a German template. Still I'd like to request a change for #invoke to accept single curly braces as table delimiters. Are any #invoke calls with params containing single curly braces out there yet? If bound to parsing a string describing a struct, I couldn't use '=' within that string. That's ugly. --Vollbracht (talk) 16:06, 13 December 2021 (UTC)[reply]
I'm not sure if this would work, but if your {...} code string was json compliant you could posssibly use mw.text.jsonDecode to create a table. The Lua Reference Manual is rather terse in its description, so I'm not sure if this is what it does. —  Jts1882 | talk  16:31, 13 December 2021 (UTC)[reply]
I think the easiest way to do this is a Lua data structures in subpages of the module. You'd have your main module at Module:Vollbracht's royal lineage and your data would be at something like Module:Vollbracht's royal lineage/Harry, which would contain:
return {
  {["n-type"]="first",
   ["content"]={{["n-value"]="Harry", ["description"]="H.r."}}},
  {["n-type"]="throne",
   ["content"]={{["n-value"]="Henry I.", ["crown"]=true},
            {["description"]="H.nr. 1st, Boss of Foo and Bar"},
            {["n-value"]="Big Baboo", ["description"]="unofficial"}}}
}
You could then call {{#invoke:Vollbracht's royal lineage|main|Harry}}, which would use 
input = mw.loadData("Module:Vollbracht's royal lineage/" .. frame.args[1])
. --Ahecht (TALK
PAGE) 18:17, 13 December 2021 (UTC)[reply]

In the end users should create an info box containing the data. This must not be complicated, so I won't expect s.o. to create separate royal lineage modules. (Still: thank you for showing up this solution!) Even mw.text.jsonDecode is sub-optimal. It would require the users to write even param names in double quotes.

It should be possible to write a parser which uses a template for the structure of the data it shall parse. So the template developer defines such a structure in a json string which his module passes to the parser together with the template user's data. Now, if the template expects a "first"-param in a row, it could reply with "unknown parameter: fist". Any ideas for necessary or sensible specifications for the parser or the json string? --Vollbracht (talk) 23:00, 13 December 2021 (UTC)[reply]

If you where to rename the param names so there is not a minus there, then you do not need to use double quotes for them. If you do want to go that route you would avoid all characters under mw:Extension:Scribunto/Lua_reference_manual#Tokens .
Separate royal lineage modules are not needed. An template with numbered parameters would need to explicitly define each parameter, where as an module only needs one definition per each group (that is, handle all parameter names that consist of number + word in a certain way). An module could also power multiple templates easily, where as that is unlikely in a template. Modules are much less complicated than wikicode templates, and modules are modular, where as wikicode is not.
I would assume the n in the parameter names actually stands for a number, which could be anywhere from 1 to 100 or even indefinate.--Snævar (talk) 20:37, 14 December 2021 (UTC)[reply]
Well, yes, I want to program a module. And no, in the end it's about name types by which name information shall be sorted: display Horus name information before throne name information before given name information and so on.
This thread is about passing a struct from wikicode to module to reduce interface width just as you recognized: the old style has had numbered parameters like throneName1Code, throneName1Description, someThroneName1ControllParam, someOtherThroneName1CP, throneName2Code, etc. up to 10 and same with a couple of other name types giving a still not sufficient total of about 100 possible params. --Vollbracht (talk) 02:48, 16 December 2021 (UTC)[reply]

District map of Moscow is missing districts

I was told to ask about this here.

The map of Moscow used on pages about its districts seems to be missing some. Maryino District shows up fine, but Metrogorodok District (north-east) among others is not marked in green at all. This seems to be based on Template:Moscow district OSM map and I am not proficient enough to make sense of it. If someone would be willing to correct this, I send my thanks. SuperJendrej (talk) 21:54, 13 December 2021 (UTC)[reply]

That is Wikidata code. Reposted at d:Wikidata:Project chat#Russian district map. The color on Metrogorodok should be red, since the map shows where the district is, but on other pages the district would be green.--Snævar (talk) 12:17, 17 December 2021 (UTC)[reply]

Edit from "What links here"

Resolved
Tracked in Phabricator
Task T297744

Why can't I go directly to edit page from "What links here" (alt-shift-j) anymore? Anyway to get it back? Or is it a new bug? Christian75 (talk) 14:13, 14 December 2021 (UTC)[reply]

I don't recall an Edit tab on "What links here". Are you referring to the shortcut Alt+⇧ Shift+e? I don't know whether that used to work. It doesn't work for me now. I have Vector, Firefox, Windows 10. PrimeHunter (talk) 15:12, 14 December 2021 (UTC)[reply]
@Christian75: are talking about the results page for WLH (try this example)? I see (links|edit) on each line there. — xaosflux Talk 15:53, 14 December 2021 (UTC)[reply]
Hmm, do you mean that at the top of the page the "edit tab" control is not there? When did you last see it there? — xaosflux Talk 15:56, 14 December 2021 (UTC)[reply]
Possible regression, seems similar to phab:T165010. — xaosflux Talk 16:00, 14 December 2021 (UTC)[reply]
It's that one, thanks. I'm using monobook and in the menu to the left "tools" it is called "What links here", and the shortcut i Alt+⇧ Shift+j. Christian75 (talk) 16:09, 14 December 2021 (UTC)[reply]
Hmm. I guess it isn't that phab because it happend today (and that phap is from 2017). Normally you could edit a page from here: [1] Christian75 (talk) 16:12, 14 December 2021 (UTC)[reply]
@Christian75: WP:ITSTHURSDAY, if I understand your report correctly, you expect an "edit" tab at the top of the page there, and it is not there. That phab was an example of when something like this broke in the past. I understand that it isn't working today, can you recall the last time that it was working though? — xaosflux Talk 16:23, 14 December 2021 (UTC)[reply]
Here is a non-Wikimedia wiki on an old MediaWiki version 1.27.7 from 2019: https://rationalwiki.org/wiki/Special:WhatLinksHere/Wikipedia. It has an Edit tab and Alt+⇧ Shift+e works. I guess I just never noticed the tab because I don't edit the page itself from WhatLinksHere. PrimeHunter (talk) 18:54, 14 December 2021 (UTC)[reply]
It seems like a bug. I filed T297744. Matma Rex talk 19:00, 14 December 2021 (UTC)[reply]
The buggy change has been reverted for now. Legoktm (talk) 04:15, 15 December 2021 (UTC)[reply]

Reply tool headed your way in January 2022

Just a heads-up that in about a month, the [reply] tool will be enabled, default-on, for all editors here. Please make a note of:

If you somehow haven't tried this out yet, then click on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)?dtenable=1 to reload this page, and look for all the little [reply] buttons after each signature. The Reply tool will auto-sign and auto-indent your comments, has an easy ping (just type @ to see a list of previous participants in the discussion), and you can choose between visual and wikitext source modes. Only the [reply] tool will be enabled in January. Everything else (e.g., the [subscribe] button) will wait for a future date. You can opt in now at Special:Preferences#mw-prefsection-betafeatures. Once you've opted in, you can adjust your prefs at Special:Preferences#mw-prefsection-editing-discussion (e.g., if you want topic subscriptions now, or if you don't want the simplified/auto-signing ==New Discussion== tool).

Whatamidoing (WMF) (talk) 19:54, 15 December 2021 (UTC)[reply]

Also: Their next projects involve getting the Reply and New Discussion tools on mobile, where the talk page experience is generally poor, and doing some work to make the pages more useful. (mw:Naming things is hard. I've been calling it "Usability", but "Usefulness" might have been more descriptive.)
As a heads-up on that – which you'll probably see in a few months, if you enable the Beta Feature and you use Vector – this Useful Usability Thing is going to involve changing the appearance. This is because when you add new useful features, you have to have a place to stick them. Also, some newbies seem to have difficulty noticing that the talk page is not the place to post their would-be articles, and they think this is partly because the pages look too similar. Even doing something fairly small, like making the ==Level 2== section headings use the "wrong" (sans serif) font, might help with that. So if you flip the Beta Feature on (so far, I'm loving it) and your talk page suddenly looks different in a couple of months, then don't panic. Just tell me what you think of it, and go to Special:Preferences#mw-prefsection-editing-discussion to flip it off if you don't like it. Whatamidoing (WMF) (talk) 20:02, 15 December 2021 (UTC)[reply]
Trying it out right here. This is pretty great, kudos.  — Scott • talk 20:12, 15 December 2021 (UTC)[reply]
I'm glad that you like it. About a half million comments have been posted via the Reply tool now. It seems to be pretty popular. Whatamidoing (WMF) (talk) 20:19, 15 December 2021 (UTC)[reply]
YES! Enterprisey (talk!) 20:26, 15 December 2021 (UTC)[reply]
  • @Whatamidoing (WMF): Is the new-page-creation workflow hijack by discussion tools (see mw:Topic:Wiggfwdwlg1hu8be) going to be the new default for everyone? For example, clicking on this redlink seems to no longer go to the new page workflow, but to the DT widget. Perhaps the editor is just trying to do something like add a banner, simply "following a redlink" doesn't mean you want to "start a disucssion". — xaosflux Talk 14:42, 16 December 2021 (UTC)[reply]
    Maybe some day, but definitely not in January. They're still working on the main test to see whether it was a good/bad/neutral idea. Whatamidoing (WMF) (talk) 19:30, 16 December 2021 (UTC)[reply]
    @Whatamidoing (WMF): ok thanks, hard to test what "will be" in that workflow right now :) So long as this is something that (a)can be disabled and (b)doesn't break what happens when you follow a red link, I can't see it being anything but a net positive. — xaosflux Talk 19:59, 16 December 2021 (UTC)[reply]
    What "will be" is what all the wikis except Meta-Wiki, enwiki, fiwiki, ruwiki, and Wikispecies already have, so you could go to Commons or dewiki or eswiki to try it out now. (Around January 12th, half the users at 20 of the Wikipedias will get a new feature as part of that test, so this won't always be true, but for right now, what they've got is what we will get.) Whatamidoing (WMF) (talk) 18:26, 17 December 2021 (UTC)[reply]

copy link to highlight

Hello developers

the feature of "copy link to highlight" in google chrome was recently intruded, can you develop the reference box to accept such links?, the benefit is known to editors and reviewers, a lot of references are to long to read, but when the citation goes right to the line from which the info was taken it would be time saving.--Abu aamir (talk) 14:13, 16 December 2021 (UTC)[reply]

@Abu aamir This feature just appends a URI fragment like #:~:text=This is the text I want to highlight to the URL. Editors can simply include this in the URL when adding citations. If I understand you correctly, there's nothing developers can do to help the situation. But nonetheless I agree it would be good practice to start doing this. Perhaps it's worth documenting at WP:CITE or elsewhere. This feature apparently isn't unique to Chromium and it is likely a matter of time before all major browsers support it. — MusikAnimal talk 00:39, 17 December 2021 (UTC)[reply]
Hello :@MusikAnimal
thanks, I just have tried the URI fragment in English Wikipedia, it worked.--Abu aamir (talk) 11:52, 19 December 2021 (UTC)[reply]
I would HATE that. There's no guarantee the page will not change or that everyone who clicks the link will see it (e.g. some may see a paywall), and citing URLs with fragments like that makes maintenance harder (e.g. in case of a link rot) and reusing the same source to support different statements needlessly difficult. If anything they should be removed—not added—just like UTM parameters. If indicating the relevant portion of a source is somehow desired, |quote= is right there. Nardog (talk) 12:36, 19 December 2021 (UTC)[reply]
If the text is no longer present, it simply wouldn't highlight anything (the status quo), so I don't see how it could effect link rot. In fact, if given an |access-date=, IABot will find the closest matching archived copy which in most cases should yield a still-working URI fragment. To me the practice seems harmless. You make a good point about reusing sources, but using |quote= would seemingly have the same problem. — MusikAnimal talk 17:19, 19 December 2021 (UTC)[reply]
Since we try to be semantic with citations, it would be better if the text is added in |quote= param and Module:CS1 automatically inserts the URI fragment, if it's short enough to be highlightable. – SD0001 (talk) 06:25, 20 December 2021 (UTC)[reply]

Missing Great Lakes

Tracked in Phabricator
Task T288897

Hi all... just been looking at one of Wikipedia's map functions, and it looks like North America is short two of its Great Lakes... it may just be my browser (Safari 15.1), but have a look at this and see if you also see the problem... Grutness...wha? 15:24, 16 December 2021 (UTC)[reply]

There for me, too, with Firefox 94.0.2. I assume it's a rendering issue (if that's the word i want), nothing more serious, as it also shows places called "nd Rapids", "ittsburg", and "nd du Lac" among others. Funny look, though. Happy days ~ LindsayHello 15:59, 16 December 2021 (UTC)[reply]
Missing for me on Chrome 96.0.4664.93 as well. ah yes, the coveted land border between Michigan and Ontario! Curbon7 (talk) 00:56, 17 December 2021 (UTC)[reply]
nothing more serious [verification needed] -- GreenC 04:37, 20 December 2021 (UTC)[reply]

Correct ID in Template:British-Museum-db

In Nimrud lens putting the identifier W_-90959 at {British-Museum-db|90959|id=W_-90959} produces nothing. Template:British-Museum-db says it relies on "&objectId=" parameter value in the URL of the British Museum collection database record for the item. However, now it seems the museum no longer uses it, e.g. https://www.britishmuseum.org/collection/object/W_-90959. Could someone help? Brandmeistertalk 16:47, 16 December 2021 (UTC)[reply]

@Brandmeister The BM has changed their system. The link in your example needs changing from https://www.britishmuseum.org/research/search_the_collection_database/search_object_details.aspx?objectid=W_-90959 to https://www.britishmuseum.org/collection/object/W_-90959. I've changed this in the template and also the default link to the help page for the search.
However, a complication is that it doesn't work for the number ids given on the Mold cape page, which have BM registration of form 1883,1207.1 and numeric ids. These now work by modifying the registration number, prefixing with an "H_" and using hyphens as separators, as in https://www.britishmuseum.org/collection/object/H_1883-1207-1. I don't know if this was working correctly before the change, although the page is linked from the template page. —  Jts1882 | talk  17:22, 16 December 2021 (UTC)[reply]
Thanks. It seems that template documentation needs an update now, as do nearly all articles using this template where previous identifiers don't work anymore. Perhaps a bot could do those mass updates? Brandmeistertalk 17:35, 16 December 2021 (UTC)[reply]
I've updated my statement above on the Mold cape page. They've replace numeric ids for the items in the old database with ids based on the item registration number. I've changed the examples on that page so they work with the template update.
Another example at Chandragupta II needs a "C_" prefix. So does this mean prefix depends on type (C for coin)? Probably means these need to be changed and checked manually. 90 transclusions is not too bad. —  Jts1882 | talk  18:02, 16 December 2021 (UTC)[reply]

Donation requests

Hi Wiki - I gave $25 to the wiki cause, but I keep getting the incessant requests to donate. If there's any way to not make that happen anymore, that'd be great! Thanks — Preceding unsigned comment added by 2600:1000:B12A:9D1D:B990:6216:C43E:7DF4 (talk) 01:58, 17 December 2021 (UTC)[reply]

So far as I know, the only way is to adblock the elements or to register and browse while logged in. Izno (talk) 04:56, 17 December 2021 (UTC)[reply]
Welcome and thank you for your question about donations! To hide the fundraising banners, you can create an account and uncheck Preferences → Banners → uncheck Fundraising. The Wikimedia Foundation does not track the identity of IP addresses, so it doesn't know your age, income level or whether you donated in the past.
None of the Wikipedia volunteer editors here who add and improve content in articles receive any financial benefit. We all simply contribute our time because we care about building a great encyclopedia for you and innumerable others around the world to use.
If you cannot afford it, no one wants you to donate. Wikipedia is not at risk of shutting down, and the Wikimedia Foundation, which hosts the Wikipedia platform and is asking for these donations, is richer than ever.
We are led to believe that users who allow cookies are less likely to see these banners on repeat visits (further information is available here), and you are welcome to communicate directly with the donor-relations team by emailing donate@wikimedia.org. Thank you! ― Qwerfjkltalk 08:38, 17 December 2021 (UTC)[reply]
Although we welcome your comments, this page is a forum for the Wikipedia community: the unpaid volunteers who write and maintain this encyclopedia. The WMF inserts the appeals into Wikipedia, and receives the resulting donations. The WMF can also be contacted at m:Talk:Fundraising. Certes (talk) 12:37, 17 December 2021 (UTC)[reply]

Name update after renaming

Hello! So as you can probably see my account has been renamed. However it appears that some lists no longer include me because they have my old username on the list instead of my new and current one. Would it be possible for someone to assist me in updating my username on any lists that include mine? I've already updated a few however I would like assistance fixing the rest. ― Blaze WolfTalkBlaze Wolf#6545 14:30, 17 December 2021 (UTC)[reply]

Which list(s) are you talking about? —GMX🎄(on the go!) 15:20, 17 December 2021 (UTC)[reply]
@PorkchopGMX (on the go): I'm honestly not exactly sure. I know the signpost is one of them however i've added my name to various things that I can't remember all of them. ― Blaze WolfTalkBlaze Wolf#6545 15:49, 17 December 2021 (UTC)[reply]
You can try WhatLinksHere from your old userpage. — xaosflux Talk 16:26, 17 December 2021 (UTC)[reply]
That won’t work for all of the lists, I see some that don’t link the userpage and/or only the user talk page. —GMX🎄(on the go!) 16:37, 17 December 2021 (UTC)[reply]
Oh, I get it now. Those are mass message lists. Is it ok if I go through your contribs and update your name in each of the lists? —GMX🎄(on the go!) 16:26, 17 December 2021 (UTC)[reply]
@PorkchopGMX:​ Feel free to do so! ― Blaze WolfTalkBlaze Wolf#6545 18:00, 17 December 2021 (UTC)[reply]
 Done, I’ve updated your username on the remaining lists.—GMX🎄(on the go!) 18:32, 17 December 2021 (UTC)[reply]
Thanks! ― Blaze WolfTalkBlaze Wolf#6545 19:05, 17 December 2021 (UTC)[reply]
Note that MassMessage follows redirects, so it's not strictly necessary to update usernames (though I understand why it would be wanted). Legoktm (talk) 02:58, 18 December 2021 (UTC)[reply]

Missing Redirects Project

Hu, would anyone be interested in generating the list from the Missing Redirects Project (if it still works)? The source code is on the page - I would run it myself if I had the technical ability. ― Qwerfjkltalk 10:16, 18 December 2021 (UTC)[reply]

I just downloaded the archive and had a look at the README.txt and a couple of other files. There is unfortunately no explicit license or statement of authorship on the code. William Avery (talk) 10:39, 18 December 2021 (UTC)[reply]
@William Avery: I think it would be safe to reuse, though not listed in every file the launcher, new-run.sh does declare: 
# Purpose : Download the latest EN Wikipedia database dump, store it, and then run our script.
# Author  : Nick Jenkins
# License : GPL v2
# Created : 25-April-2005
So long as you keep it under GPLv2 you should be fine to make derivatives. — xaosflux Talk 17:44, 18 December 2021 (UTC)[reply]
Sorry about that, and good spot. Taking a closer look at the code, I notice it refers to the cur table, from which it gets a page's text content. So I don't think it will run against a current database dump without modification, and the corresponding current dump would be pages-articles-multistream.xml.bz2, meaning somebody doing that needs to be able to handle a ~80 Gb database. William Avery (talk) 20:30, 18 December 2021 (UTC)[reply]

System for handling possibly plural infobox parameters

Example
Spouse
​
(m. 2001)​

A small but massive scale issue that has long confronted us when designing infoboxes is how to handle labels of infobox parameters that are sometimes plural and sometimes singular. There have been several approaches in wide use, each of which has had flaws:

  1. Using (s) in the label, which produces displays like the example at right. This produces a non-optimal display for readers.
  2. Changing the display based on the parameter. For the example, that would mean displaying "Spouse" if |spouse= is used and "Spouses" if |spouses= is used. However, this is highly vulnerable to error if e.g. someone remarries but editors forget to change the label. Also, it would require extensive bot work to implement en masse for parameters currently using the first approach.
  3. Changing the display based on automatic detection using {{Detect singular}}. For the example, this would mean the infobox would display "Spouse", but would switch to "Spouses" if a second spouse was added. However, {{Detect singular}} is not perfect, and this option cannot be used widely without a way to correct the rare errors.

Following several rounds of previous discussion, we've recently introduced a simple method for overriding the rare {{Detect singular}} errors (just use e.g. |spouse=Charles, Prince of Wales{{force singular}}), which makes the third approach a lot more appealing.

Given all this, I'm opening this discussion to affirm general consensus for the third approach. If there's agreement to move forward, the next step will be to have discussions at individual infoboxes before implementation. Local consensus will be allowed to override if there are any concerns, but if not this will be presumed the standard best practice. Thoughts? {{u|Sdkb}} talk 23:33, 18 December 2021 (UTC)[reply]

Courtesy pinging prior discussion participants:@BilCat, Jonesey95, RexxS, GhostInTheMachine, Funandtrvl, AlanM1, Hike395, Gonnym, and Shushugah: {{u|Sdkb}} talk 23:44, 18 December 2021 (UTC)[reply]
(has hammer)
Extended content
Not sure if my answer will be of any interest to the subject but I've happened to be working with infoboxes these past few months, importing a lot of them from here for my homewiki (SqWiki) and they suffer a lot from the i18n aspect. A lot of them have if statements that guarantee different text for plural and singular cases which in practical sense means adding or not an extra "S" but that totally breaks outside of English. Having if statements for English vs American spelling reasons again makes no sense outside EnWiki. Or having ifexist statements in wikilinks hardcoded in English syntax (see {{infobox country}} geography of or politics of parts - fully breaks in every language that uses declensions). These are only a few cases of the same phenomenon. I've been a bit more detailed in this topic here. I'm aware this discussion doesn't deal with what I'm talking about but if changes happen, maybe what I'm expressing above can also start being addressed somehow. Maybe...

- Klein Muçi (talk) 00:09, 19 December 2021 (UTC) [reply]

Notified: WT:MOSINFOBOX. {{u|Sdkb}} talk 23:44, 18 December 2021 (UTC)[reply]
I like this third approach. For the 90% of editors who aren't deeply familiar with templates, they can move along happily, and for the edge cases, we have transparent {{force singular}} and {{force plural}} overrides. ~ 🦝 Shushugah (he/him • talk) 23:53, 18 December 2021 (UTC)[reply]
I've been adopting the 3rd method and in the infoboxes I work with I've yet to encounter a need for the 4th method. Even in a case like Charles, Prince of Wales can be handled automatically by telling the {{Detect singular}} to count the number of links. In this case, there is one link which would mean singular entry. In any case, if the need requires the force templates, that should be a per template discussion and not a global one. Gonnym (talk) 14:15, 19 December 2021 (UTC)[reply]
On the other hand, your idea of counting links would screw up cases like William Jefferson Blythe Jr., who has multiple wives listed but only one is a link (FYI, he and the linked wife are Bill Clinton's parents). 93.172.224.115 (talk) 20:33, 19 December 2021 (UTC)[reply]
Since we're already focused on edge-cases, let's be sure we don't break things further for the range of related edge-cases there might be. What if there are multiple entries that include commas in them? As an actual example, the children of Henry VIII are:
  • Henry, Duke of Cornwall
  • Mary I, Queen of England
  • Henry FitzRoy, Duke of Richmond and Somerset (ill.)
  • Elizabeth I, Queen of England
  • Edward VI, King of England
It's a fundamental problem that already has multiple approaches to address when the delimiter between items is an actual valid component of items themselves. Rather than tagging the whole field, it might be simpler to mask the comma character itself so it is the correct character but be parser-recognizeable as a non-delimiter character DMacks (talk) 22:23, 19 December 2021 (UTC)[reply]
There's definitely room for some further improvement of {{Detect singular}}. If you or anyone else here would like to work on that, please do! {{u|Sdkb}} talk 01:46, 20 December 2021 (UTC)[reply]

Infobox military conflict - I18n

Hello! I've recently made a question in Template talk:Infobox military conflict regarding I18n and the template's technical nature but I've gotten no answer there for many days no. I thought I could try my luck here. Can someone with some extra time take a look at my question there? I hope what I've written does make sense. My technical terminology is not that good. - Klein Muçi (talk) 23:49, 18 December 2021 (UTC)[reply]

{{subst:template}} leaves {{#if}}

Hi, I'm currently trying to make a template, and I need your help (note that this is just for personal use). I'll just simplify what I'm trying to do, it's something like when you input a value for parameter 1 (a username), you'll get:

and when you input values for parameter 1 and 2, you'll get:

and so forth. I then tried the following (see Special:PermaLink/1060989898 for the original (coloured) code, and Special:PermaLink/1060989936 for its actual output): 

<includeonly>{{ {{{|safesubst:}}}Ifsubst||{{Subst!|}}}}</includeonly>
* {{User|{{{1}}}}}{{#if:{{{2|}}}|* {{User|{{{2}}}}}}}

When I use this with {{subst:template|Example|Example2}}, I get the result I want. But when I look at the source text, it has {{#if}} left over like the following:

* {{User|Example}}{{#if:Example2|* {{User|Example2}}}}

What I want is the source text of: 

* {{User|Example}}
* {{User|Example2}}

How can I do this? Thank you for your help in advance. --Dragoniez (talk) 23:55, 18 December 2021 (UTC)[reply]

Put {{{|safesubst:}}} before #if in the template. – SD0001 (talk) 07:48, 19 December 2021 (UTC)[reply]

CodeEditor changes?

Here are lines 2 and 3 from Module:No globals: 

function mt.__index (t, k)
	if k ~= 'arg' then

It used to be that CodeEditor would report the 'columnar' position of the cursor at the right edge of its footer taking into account the width of a tab character (4) so that if I placed the cursor between the tab character on line 3 and the i of the if keyword, CodeEditor would account for the columnar width of the tab character. Not so anymore; it now ignores the columnar width of the tab character and reports '1'.

When did this change? Why did this change? Should it have changed?

Also, somewhat related, didn't there used to be a help link in the CodeEditor header?

—Trappist the monk (talk) 17:21, 19 December 2021 (UTC)[reply]

as far as i know, it has always reported character offsets, not column offsets, and 1 tab is 1 character. —TheDJ (talk • contribs) 17:44, 19 December 2021 (UTC)[reply]
Based on Wikipedia talk:Lua style guide § CodeEditor switched to tabs, after a few months of deployment, the code editor changed from inserting spaces to inserting tabs. Perhaps you have been looking at some code that was written back then? Or someone manually entered in spaces? (Although that's a pain to do with the auto-indenting feature automatically entering tabs.) isaacl (talk) 21:05, 19 December 2021 (UTC)[reply]
I have used CodeEditor a lot. I prefer tabs to spaces so I notice it when I encounter all those damn space characters in another editors' work; I tend to think the editor (especially for recent work) used the wikitext editor or used an external text editor to create/maintain some bit of code. I am pretty sure that I remember CodeEditor accounting for tab width but, of course, I could be wrong. It seems to me odd that I would only notice that now having spent all these years with CodeEditor.
—Trappist the monk (talk) 23:00, 19 December 2021 (UTC)[reply]

Apparent bug in recent(?) Mediawiki(?) change to article reference link mechanism

I noticed a problem for a particular reference/footnote mark (superscript "[3]") in Ecdysozoa (but now only in this recent version since I put a workaround into the article). The problem is that (1) hovering over the mark does not pop up the reference contents as usual, and (2) clicking on the mark does not take you to the entry in the References section. In the linked version, this happens for notes [3] and [4], and a later one, but the problem does not happen on the other reference marks.

The problem looks to be due to a bug in a change to the html anchors used for references when a reference name is given and the name includes the string %20. For instance in the above version, the reference [3] name was "nature%20phylo" and this caused html usages <li id="cite_note-nature%20phylo-3"> and <a href="#cite_note-nature_phylo-3"> and this mismatch probably caused the lack of the popup and failure to scroll. I changed the reference name to "nature_phylo" in the current version, and this avoided this instance of the problem.

There may be dozens to gazillions of such reference names scattered about articles, so this needs attention. I have no idea what piece(s) of software might be involved or how to get fix work going. --R. S. Shaw (talk) 20:40, 19 December 2021 (UTC)[reply]

There's maybe just a dozen or so instances (times out). I'd just fix them and if you really think it's necessary, file something in the Cite project on phab:. Izno (talk) 22:03, 19 December 2021 (UTC)[reply]
Why do you want encoded spaces? If you use normal spaces, the MediaWiki software will transparently perform any encoding that is necessary. --Redrose64 🌹 (talk) 23:11, 19 December 2021 (UTC)[reply]
I don't care in the least about spaces in reference "names". I had never visited that page before and I just cared about being able to see the references - but they were broken because somelone had used %20 in the "name". This occurs in an unknown number of other arbitrary articles. --R. S. Shaw (talk) 00:38, 20 December 2021 (UTC)[reply]

Performance charts?

I want to build a little dashboard showing the length of the various WP:SPI queues over time. Rather than reinvent many many wheels, what I'd like to do is just write a little data shim that throws numbers at some pre-existing dashboard system such as Graphite (software). Does such a thing exist in wiki-land? -- RoySmith (talk) 23:25, 19 December 2021 (UTC)[reply]

Something via {{Graph:Chart}}? There are some interesting examples and other graphs at Wikipedia:Statistics. DMacks (talk) 23:43, 19 December 2021 (UTC)[reply]
WMF used to use Graphite for their statistics, then it moved to Grafana/Prometheus. There is also an unmaintained Grafana extension to display data onwiki. The underlying extension behind Graph:Chart, mw:Extension:Graph, can be used in an interactive way and you can feed it data from the API, so maybe give it a chance.--Snævar (talk) 00:09, 20 December 2021 (UTC)[reply]
Thanks, Graph:Chart looks like it might be what I want, although I'm not seeing how you get it to graph data from an API. I had once enquired on the cloud mailing list about this stuff and was pointed to Prometheus, but it looks like it's not really meant for public consumption. You need to log in to a private admin site, sign an NDA, etc. -- RoySmith (talk) 01:10, 20 December 2021 (UTC)[reply]
Since all the SPI queues have dedicated categories, you could use User:MusikBot/CategoryCounter to automate populating a JSON page with the sizes of the categories over time. That can easily be fed into a chart using {{category chart}}, though currently you can only show one dataset per chart. — MusikAnimal talk 04:00, 20 December 2021 (UTC)[reply]
Ah, cool. This led me on a fun romp exploring mw:Extension:Graph, and Vega, and some obtuse corners of wiki markup. I've added an entry to User:MusikBot/CategoryCounter/config; please feel free to back that out if it breaks anything. I think I've got all the basic pieces here to build what I want without any new wheel inventing. Thanks! -- RoySmith (talk) 14:48, 20 December 2021 (UTC)[reply]

Lag while typing in long threads but no lag in edit summary

Or in subject lines, or new threads such as this. What's causing it? Doug Weller talk 10:25, 20 December 2021 (UTC)[reply]

Could be related to Wikipedia:Village pump (technical)/Archive 193#Performance issue with syntax highlighting – SD0001 (talk) 12:32, 20 December 2021 (UTC)[reply]
I get this lag too, even with syntax highlighting disabled. I wasn't experiencing this like a month back. ProcrastinatingReader (talk) 12:33, 20 December 2021 (UTC)[reply]
If you're on Chrome, try turning off the spellchecker. – SD0001 (talk) 12:39, 20 December 2021 (UTC)[reply]
Or switch to the 'enhanced' spell check. But be mindful of your privacy because whatever you type goes to google...
—Trappist the monk (talk) 13:10, 20 December 2021 (UTC)[reply]
The bug has been fixed, but it will take a while for it to get into the release Chrome versions. In the mean time, Trappist's workaround will work. Rlink2 (talk) 13:55, 20 December 2021 (UTC)[reply]
I meant to come back here and say that User:Trappist the monk's suggestion did indeed solve the problem. Thanks all. Doug Weller talk 14:43, 20 December 2021 (UTC)[reply]

Extended-confirmed user cannot move over ECP-create-protected title

Resolved
 – Was a title blacklist issue, not a protection bug. — xaosflux Talk 16:09, 20 December 2021 (UTC)[reply]

For a long time, I have been setting "extended confirmed" create protection on article titles that have had a history of repeated creations and deletions, so that a user with extended-confirmed privilege can move a reviewed-and-approved draft to that title without needing to involve an administrator.

However, something isn't quite right. An extended-confirmed user notified me on my talk page that s/he is unable to move a sandbox draft to the create-protected title Kobi Arad. The user, MerliSter, has the extended-confirmed user right but gets a message that one needs to be an administrator to perform the move.

What is going on? It is reasonable to expect that EC users should be able to create articles on ECP titles. ~Anachronist (talk) 14:42, 20 December 2021 (UTC)[reply]

Just tried this myself and it seems to be because the title matches an entry ( .*kobi ?arad.* # [[Wikipedia:Miscellany for deletion/Draft:Kobi Arad]] on the title blacklist. —GMX🎄(on the go!) 14:57, 20 December 2021 (UTC)[reply]
Ah, I see. That explains it. Thanks. ~Anachronist (talk) 15:58, 20 December 2021 (UTC)[reply]

No horizontal scrollbar on wide tables

Resolved
 – Seems to have fixed itself

--Andyross (talk) 17:13, 20 December 2021 (UTC)Not certain where the bug is, but on the Roku page, there are several very wide tables with device info. In both MS Edge and Firefox, there is no horizontal scroll bar. Is this a page issue, or something with the code Wikipedia is generating?--Andyross (talk) 15:04, 20 December 2021 (UTC)[reply]

On Firefox, I get a scroll bar across the bottom of the window allowing me to move the entire article sideways and see the rightmost columns. Should I expect another scroll bar specific to the table itself? Certes (talk) 15:25, 20 December 2021 (UTC)[reply]
I, too, get a whole-page scrollbar on my Firefox (94.0.2 (64-bit)). Don't know why you're seeing anything different. I will point out, though, that there is only one table on that page (besides, technically, the infobox). — JohnFromPinckney (talk / edits) 15:49, 20 December 2021 (UTC)[reply]
Odd. Now it's there in both browsers. Maybe some sort of weird glitch at the time from the servers.--Andyross (talk) 17:11, 20 December 2021 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1061259794"