Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Titore (talk | contribs) at 02:47, 27 August 2023 (→‎Orange bar of doom seems to be broken: +tracked). 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).

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.

Dated maintenance categories

Wanted to ask about an issue that I've noticed with dated maintenance categories. This isn't the only time this has happened, and instead there have been a lot of examples of this of late, but I'll raise Category:CS1 maint: DOI inactive as of December 2022 as an example since that's the most recent case I've located.

What happened is that it was deleted as empty on August 1, but then sometime in the next week it somehow became repopulated, with the result that I had to undelete it on August 7 to get it off Special:WantedCategories, but then sometime in the week after that it was emptied again and thus had to be deleted a second time.

Now, obviously, there's no value in tagging dated maintenance categories for the "keep even if empty, because a possibility of future reuse exists" option that general undated maintenance categories sometimes get — but I don't see any great value in Wikipedians going through a looping delete-undelete-redelete cycle on them either. So is there any alternative way that could have avoided this, such as having the maintenance template only generate dated categories if they actually exist, and substituting a generic undated "crapcatcher" category if they don't, so that such situations are prevented from showing up as "wanted" redlinks? Bearcat (talk) 13:03, 20 August 2023 (UTC)[reply]

I guess a page reappeared in the category because it was reverted to a revision with that dated tag. A template would have to use #ifexist to omit red categories but it's an expensive parser function with 500 total allowed per page. That could cause problems on pages with many such templates. It would also delay creation of new maintenance categories. I would like a MediaWiki feature like regexes in a MediaWiki message to say that certain category names should be treated as hidden categories if they don't exist. Then normal readers and registered users with default settings wouldn't see an ugly red link in the category list. It wouldn't solve your problem but I think this is a more important problem with red maintenance categories. PrimeHunter (talk) 14:41, 20 August 2023 (UTC)[reply]
Many of the actual maintenance templates do use #ifexist (mostly via Template:Dated maintenance category or Template:Fix/category or Module:Message box) to populate Category:Articles with invalid date parameter in template. Then AnomieBOT's DatedCategoryCreator task looks through that category every 2 hours to find articles that have redlinked dated subcats of categories in Category:Wikipedia maintenance categories sorted by month and Category:Wikipedia categories sorted by month to automatically create them. Whether it would be appropriate to have the CS1 templates do something similar I don't know. Anomie⚔ 18:11, 20 August 2023 (UTC)[reply]
Given the number of uses on our largest pages, not likely. Izno (talk) 18:20, 20 August 2023 (UTC)[reply]
Umm, are you sure? The only dated maint cats that cs1|2 populates are subcats of Category:CS1 maint: DOI inactive. Presently, there are ~2k articles that have |doi-broken-date= (all of them in Category:CS1 maint: DOI inactive as of August 2023). Since the dated maint cat is dependent on |doi-broken-date=, the cs1|2 module would only have to call the expensive function mw.title.new ('Category:CS1 maint: DOI inactive as of <month> <year>').exists when |doi-broken-date= is found. I doubt that there will be more than 500 of those parameters in a single page. When |doi-broken-date= is found without a matching extant category, the module can emit the red-linked cat plus a blue-linked cat for AnomieBOT which can then somehow create a blue-linked cat from the red-linked cat. Does AnomieBOT add all of the wikitext presently in the category page itself or is that an exercise left to editors?
—Trappist the monk (talk) 18:48, 20 August 2023 (UTC)[reply]
AnomieBOT creates the dated categories with either {{Monthly clean-up category}} or {{Monthly maintenance category}}. See Category:Articles with unsourced statements from August 2023 or Category:Uncategorized from August 2023 for some examples. If we want to we could do a different template for CS1 maint cats, of course, but I'd still recommend the category page transclude a single template (whether that's like {{CS1 maintenance category}} or {{CS1 maintenance category/DOI inactive}} or maybe even {{CS1 maintenance category|DOI inactive}}) so it's easy for people to adjust the contents without needing changes to the bot. Anomie⚔ 19:44, 20 August 2023 (UTC)[reply]
I thought the bot would recreate a deleted category if it were repopulated? I assume this wouldn't require a lot of work, just a periodic check of "TOPIC as of MONTH YEAR"; there are a lot of possibilities of course (272 months have passed since Wikipedia was set up, and that's for each topic category: 272 "unsourced articles as of", 272 "NPOV issues as of", etc), but it shouldn't be hard for a bot. Nyttend (talk) 11:42, 21 August 2023 (UTC)[reply]
Not hard to program, but time and resource consuming. Which is why the bot currently relies on Category:Articles with invalid date parameter in template to flag the articles having problematic categories instead of querying 54000 category names every few hours. Anomie⚔ 12:14, 21 August 2023 (UTC)[reply]
I'm beginning to think that an automated solution utilizing AnomieBOT doesn't fit here. The example category, Category:CS1 maint: DOI inactive as of December 2022, is not named properly for AnomieBOT (it wants ... from <month> <YYYY>). It isn't clear to me how to apply either of {{Monthly clean-up category}} or {{Monthly maintenance category}} where the desired category title uses a date that isn't current-month and current-year.
I'll think some more about this and continue the discussion at Help talk:Citation Style 1.
—Trappist the monk (talk) 17:49, 21 August 2023 (UTC)[reply]
Neither of those are insurmountable if people at Help talk:Citation Style 1 decide they'd want AnomieBOT's help. If they decide they want it, let me know on User talk:AnomieBOT. Anomie⚔ 19:41, 21 August 2023 (UTC)[reply]
Update: As of the latest run of Special:WantedCategories, Category:CS1 maint: DOI inactive as of December 2022 was repopulated again by a new page that was not even the same page as the last time it repopulated, meaning I had to recreate it a third time. Bearcat (talk) 12:42, 25 August 2023 (UTC)[reply]
The relevant pages are Native American use of fire in ecosystems today, and Schizoid personality disorder before. In both cases a citation that was populating the category was caught up in an unrelated edit war. I ran Citation bot to remove today's page from the report, and I suspect neither of those pages are going to show up again in the report, but obviously there's nothing I can do about other pages. * Pppery * it has begun... 14:31, 25 August 2023 (UTC)[reply]
I have to ask, is there any value in the template actually generating dated monthly categories at all? Given that as of right now the dated monthly for August is the only one left, is there a reason why it can't just throw everything into one undated category and stuff anything that would cause problems like this to even occur in the first place? Bearcat (talk) 20:33, 26 August 2023 (UTC)[reply]
My understanding is that Headbomb keeps the dates up to date. He can give voice on the point. Izno (talk) 21:05, 26 August 2023 (UTC)[reply]
I'm not doing anything wrt to dated DOI categories. Someone else is though. The solution here really is that when some old broken DOI is found, just run citation bot on the page and it'll update to a modern date (or get fixed). Headbomb {t · c · p · b} 00:57, 27 August 2023 (UTC)[reply]

Script space

Is there any technical reason that we don't have a namespace devoted to scripts? It occurred to me that we have spaces which encourage collaboration among editors for coding Modules, and Templates, and we even have Draft space for collaborating on articles-to-be, we don't have a space devoted to scripts, and so they are developed in User space, typically as a subpage. A negative consequence of this, imho, is that for better or worse, editors are "respectful" (not quite the right word) of user pages "belonging" to other users, and might shy from editing other users' pages more than they might a Draft, a Module, or a Template. I've been around long enough to know that no page belongs to anybody, but it's kind of an emotional thing, almost; I'm much less likely to jump onto your User subpage and start improving "your" draft, "your" template, or "your" module. But in all of those cases, the user has the option to move them to Draft:, or to Template:, or to Module: space. Not so with scripts, and I fear that this has negative consequences for collaboration on scripts. Maybe I'm all wet, and if script writers out there tell me that they happily jump in to scripts regardless what user subpage they happen to live on, then I'll be happy to hear it, and we can close this. But it almost feels like people have to ask permission or something before messing with a user script.

There might be some statistics we could look at to try to assess whether this is, or isn't a problem, and I've asked the nice folks over at WP:QUERY to see if they can enlighten us, and will link this discussion and report back. Thanks, Mathglot (talk) 02:04, 21 August 2023 (UTC)[reply]

For me, it's not about being respectful by choice. When I go to User:Mathglot/ShowRevisionID.js, I see "View source" instead of "Edit". I can't edit that page, even if I am 100% confident in my proposed change. I have Template Editor rights but I am not an admin. If only admins can edit other editors' .js pages, it seems highly unlikely that a collaborative culture of script editing would develop in User space. If that makes sense. – Jonesey95 (talk) 02:15, 21 August 2023 (UTC)[reply]
Admins cannot edit .js pages, only the owner or interface admins. That's a security issue because js runs on the user's browser and is an uncontrollable language able to do a lot of damage. By comparison, templates and modules use a well-defined and locked down language that runs on monitored servers. Johnuniq (talk) 02:22, 21 August 2023 (UTC)[reply]
That page says that there are only 12 current interface admins. I think that reinforces my point above. – Jonesey95 (talk) 02:29, 21 August 2023 (UTC)[reply]
Yes, it reinforces your point but it also reinforces mine, namely that js pages are a security problem and opening them up to more than a dozen or so people will not and should not happen. Johnuniq (talk) 02:37, 21 August 2023 (UTC)[reply]
Whoa, I'm surprised! That would seem to argue strongly in favor of a new namespace, and a new privilege. Why shouldn't trusted editors be able to collaborate on scripts as they do on modules and templates? I don't really see that the security issue is a problem, because we all get to import or otherwise install somebody else's script on our common.js, and the same thing would apply, even if we imported it out of Script space, instead of user space. The only difference would be that we'd have more trusted eyeballs and hands on the scripts in script space; that seems like a win-win. (edit conflict)
Putting it another way: what's better: limiting controlling potential damage to one editor-owner (plus 12 IA's), or allowing a coterie of trusted js editors to monitor and look over all the js files, regardless where they live? And additional protection could always be applied to any given page, as is the case now. Mathglot (talk) 02:48, 21 August 2023 (UTC)[reply]
A permission model allowing user-defined groups, for example, doesn't need a new namespace. Without some ability to set editing restrictions, the security issue is indeed a significant problem: I don't want anyone changing my personal user scripts without my authorization as that would allow them to trigger the execution of arbitrary Javascript code in my browser with my credentials. isaacl (talk) 03:01, 21 August 2023 (UTC)[reply]
This collaberative space could live in the MediaWiki namespace. An script living there does not make it a gadget, it is both it's location there and that it is specified in MediaWiki:Gadgets-definition that does. An distinction between an collaberative script and an gadget could be made with an prefix, Gadgets allready have one, or at least the first script in a row (like with MediaWiki:Gadget-refToolbar.js and MediaWiki:RefToolbar.js).
It is really unlikely that an new user-right would happen. Interface admins where added by the WMF and they are not interested in slacking the requirements on it. 2FA is a known deterrant for people to get IA rights and will continue being so.
It would be nice to have an database query on scripts by inactive users (that metric is well defined nowadays), so that those scripts could be moved from Inactive_user/script.js to new_maintainer/script.js, where a new maintainer is interested. Snævar (talk) 11:15, 21 August 2023 (UTC)[reply]
There are use cases where user-defined access groups are helpful to allow greater flexibility in managing who can update a specific page, though possibly more so with non-WMF deployments of MediaWiki. (For an example of how this works with a different Wiki platform, see Foswiki's documentation on access control.) isaacl (talk) 16:43, 21 August 2023 (UTC)[reply]
Isaacl, Re: "...as that would allow them to trigger the execution of arbitrary Javascript code in my browser": Don't we already have that situation now, in the case of imported scripts in common.js? Sure, it's "my" js, but I'm importing a bunch of useful scripts, and I'm trusting that the changes they make to the scripts behind my back are beneficial. I import them because I trust them, even with changes I don't see, but even a well-intentioned script change might be destructive. How is it better to have that under the control of one person, rather than a community of trusted script editors, who might jump in from any time zone when they noticed something awry? Seems to me the supposed security of having only 12 IA's isn't really there, it's a mirage, unless you don't import any scripts at all, and then you're safe.
But, your objection is still a fair one, so let's see what can be done. What if imported scripts were disabled automatically every time they were modified, and then either you could reënable it yourself (just for you, redeclaring your trust, either after looking at the script, or just trusting its author), or it would be globally reënabled maybe after an Rfc-like script Talk page discussion where the script author would explain/defend their change, and the community would respond approve, decline, needs-work? I know that bots have to go through an initial approval and beta-test period, before being allowed to run. What about afterward: is initial approval carte blanche to do whatever modification you want to the code as long as you don't call it a "new task"? Who decides what kind of bot-code change is too big to allow without approval? How is importing a script which runs in your browser and is only editable by one user, safer than one that is editable by a community of trusted users?
If we had a community of privileged script writers and automatic disabling of scripts every time they were changed, along with some mechanism to reënable them, would that satisfy your objection regarding scripts written by others running in your browser with your credentials? If we're halfway-there, and there's just a missing piece, what is it? Mathglot (talk) 01:18, 22 August 2023 (UTC)[reply]
Currently, I control when I modify my common.js file, and make an explicit decision to trust one specific user. Any change to allow users to modify other people's user scripts will be different than the current situation. I think having user-defined access groups would provide a framework for defining circles of trust, both regarding who can alter a user script, and what circle someone needs to trust before making use of the script. isaacl (talk) 02:01, 22 August 2023 (UTC)[reply]
You can already import a specific revision of a script if you don't want to risk the author going rogue or being compromised, although you then have to review each update or miss bugfixes and improvements. Everything about user scripts is a tradeoff between convenience/innovation and security. The fact we let users execute arbitrary code and that code is out in the open is unthinkable to most engineers. Reviewing each script and each change would be a tremendous undertaking neither WMF nor the community can dream to afford. But they make your life on wiki a lot easier, don't they? Nardog (talk) 02:05, 22 August 2023 (UTC)[reply]

Global account information

Not a Wikipedia issue, exactly, but I suppose people here would know the answer.

meta:Special:CentralAuth/Nyttend gives my account registration date as 30 March 2008, apparently because that's when I linked my 2-year-old en:wp, commons, and de:wp accounts. For us old-timers, who remember when you had to register accounts separately at the different projects, is there anywhere that provides each account's creation date? Or if I'm curious, do I have to look at each wiki's log page? Nyttend (talk) 11:37, 21 August 2023 (UTC)[reply]

You'd have to look at each wiki's log page. This doesn't affect you but account creation only began to be logged in September 2005. Graham87 12:01, 21 August 2023 (UTC)[reply]

Tech News: 2023-34

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

Recent changes

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 22 August. It will be on non-Wikipedia wikis and some Wikipedias from 23 August. It will be on all wikis from 24 August (calendar).

Future changes

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

15:23, 21 August 2023 (UTC)

Switcher gadget: please take a quick look

In response to MediaWiki talk:Gadget-switcher.js#Interface-protected edit request on 27 July 2023: Add space between the button and text I've made a new version of gadget-switcher that uses OOUI instead. This will make the radio buttons appear more uniformly across skins.
As this is a default gadget and the changes aren't quite trivial it should be tested by more people than just myself. Demo at https://commons.wikimedia.beta.wmflabs.org/wiki/Template:Switcher, source: https://commons.wikimedia.beta.wmflabs.org/wiki/MediaWiki:Gadget-switcher.js.
Pinging @Cmglee, Number 57, Jackmcbarn, PrimeHunter (participants in previous discussions) — Alexis Jazz (talk or ping me) 17:49, 21 August 2023 (UTC)[reply]

OOUI is not only a big library but one WMF is moving away from. Doesn't strike me as something worth making every reader of some of the most visited articles on the wiki download just so the radio buttons look slightly prettier. Nardog (talk) 01:48, 22 August 2023 (UTC)[reply]
Nardog, WMF moving away from OOUI? I was unaware, where can I read more about that? What is the replacement? — Alexis Jazz (talk or ping me) 09:57, 22 August 2023 (UTC)[reply]
Long term, OOUI will be replaced with mediawikiwiki:Codex, which is built on Vue. This was announced about 2 years ago. But OOUI is going to be around for a long while still. Transitions like this generally take 7+ years. —TheDJ (talk • contribs) 11:21, 22 August 2023 (UTC)[reply]
TheDJ, I wish someone had told me this before I invested too much time figuring out OOUI.
And now Codex. It just doesn't seem to work. "Uncaught ReferenceError: require is not defined" is all it can throw and none of these code examples has any context on how to actually use any of it. :-/ I just don't get it. The only example I could find here is User:Jdlrobson/rl.js but I don't understand what that code is doing. — Alexis Jazz (talk or ping me) 17:44, 22 August 2023 (UTC)[reply]
@Alexis Jazz I doubt OOUI will ever be removed, and I'm certain it won't happen in the foreseeable future (not until someone rewrites VisualEditor and a bunch of other things), so if you've grown to like OOUI, you can keep using it. (But if you always hated it, now you're vindicated!)
I'm not sure what's the context for your require question, but you can get that function from mw.loader.using like so: [11]
mw.loader.using( '@wikimedia/codex' ).then( function ( require ) {
    require( '@wikimedia/codex' ) ...
} );
(or you can use mw.loader.require instead, but that is "publicly exposed for debugging purposes only and must not be used in production code" [12]).
Codex is more complicated than OOUI, unless you've already used Vue.js, in which case it's more intuitive. It's also quite annoying to use from gadgets, since ideally it depends on a bunch of server-side processing. I haven't tried doing that myself yet, and I hope someone will document how to do it at some point (or make it easier).
If you're just trying to get things done, in a way that will be stable for years, I recommend the "CSS-only version" of Codex (e.g. [13]), which is way easier to understand than everything else, as long as you don't mind writing out a bunch of CSS classes in your JS code. Matma Rex talk 20:13, 22 August 2023 (UTC)[reply]
Matma Rex, I just wanted to create a "hello world" dialog. I've added your line so it no longer errors, but I still get no dialog: Wikipedia:Sandbox (revision 1171734233) Even if that worked, it's a ludicrous amount of code to produce a "hello world" popup.
As for OOUI, I have a kind of love-hate relationship with it. In some ways it's too limiting and I end up applying CSS hacks which can end up harmful, and some stuff is just really confusing. (IIRC reading/writing the options from comboboxes was confusing but it's been some time) The icons OOUI provides I don't use at all, they add considerable loading time and have a more restrictive license than my scripts, so I just designed my own icons. But these proved more difficult to apply to OOUI elements. From what I read, with Codex you can load only the icons you actually need which would seem nice. Some parts of OOUI (long names of stuff) add considerably to the size of scripts.
But in general I like OOUI. I don't have to think as much about various skins and styling. And once you get the hang of it it's okay to work with. — Alexis Jazz (talk or ping me) 23:33, 22 August 2023 (UTC)[reply]
@Alexis Jazz I got your example working with three changes: [14] (just for educational purposes)
  1. You don't need to create a HTML <template> element. The example code uses that, because the server-side processing I mentioned detects this syntax and puts it elsewhere. If you don't have that (like in a gadget), you need to use a normal string, and pass it to the component.
  2. You don't need to (and can't) do anything with module.exports. That's used when you have a ResourceLoader module consisting of multiple files. mw:ResourceLoader/Package files
  3. You were defining a reusable component, but you were not using it anywhere. In theory, once you had your DialogBasic component, you could use it as <dialog-basic> inside other components, same as you're using CdxButton / <cdx-button> (I'm not sure if that requires some other boilerplate) – e.g., in the context of MediaWiki, imagine a reusable namespace selector dropdown defined that way, or something. But if you want to display it, you need to do it yourself. Luckily this is just one line.
Matma Rex talk 15:27, 23 August 2023 (UTC)[reply]
Matma Rex, I confirm it works, thanks! As also stated by egardner on phab:T344680 it's not really streamlined enough ATM to recommend for use in gadgets or userscripts. However, it's nice to at least know how to make it work, even if it's not particularly practical ATM. — Alexis Jazz (talk or ping me) 02:19, 24 August 2023 (UTC)[reply]
The Codex story in gadgets/scripts is not well supported yet. You're looking for phab:T313945. Izno (talk) 20:54, 22 August 2023 (UTC)[reply]
@Alexis Jazz: Thank you very much for looking into this. I'm unfamiliar with Mediawiki software so cannot comment on what the correct approach is but am happy to beta-test it. https://commons.wikimedia.beta.wmflabs.org/wiki/Template:Switcher has adequate space between each radio button and its label, though there is much larger vertical separation between rows than on Template:Switcher/doc#Example: Firefox's Inspector shows that the wmflabs version has each label in a separate div where the original template has just label elements. Cheers, cmɢʟee⎆τaʟκ 16:05, 22 August 2023 (UTC)[reply]

Currently the <gallery> tag and Template:gallery which implements it, can be sized using pixel values in the |height= or |heights= parameters. The help page says that Images displayed by the <Gallery>...</Gallery> tag do not obey user viewing preferences. Is there any plan to support user preferences and the |upright= parameter as image thumbnails currently do? Or is there a reason why this will not happen? Rjjiii (talk) 03:17, 22 August 2023 (UTC)[reply]

It appears that for some reason, galleries are rendered only using px values. mw:Manual:$wgGalleryOptions sets the default pixel size of each image (more or less, apparently). Also see mw:Help:Images#Rendering a gallery of images. – Jonesey95 (talk) 04:37, 22 August 2023 (UTC)[reply]
No one has touched its code in years. The last thing that as added to it was the slideshow mode, but its core fundamentals are ancient. As such it has not kept up with other parts of the code. —TheDJ (talk • contribs) 11:25, 22 August 2023 (UTC)[reply]
Well dang. I was thinking that galleries might be a cleaner way to juxtapose images, compared to Template:Multiple image or a single image created for comparison. Thanks for all of the explanation though. Rjjiii (talk) 02:43, 23 August 2023 (UTC)[reply]

Extra space in between namespace and talk page name

Tracked in Phabricator
Task T315893

In phab:T315893, for folks that have enabled Special:Preferences -> Editing -> Show discussion activity, the editing team has decided to add a space after the colon to every talk page title. It sounds like they have plans to roll this out to non-talk pages and possibly for non-"Special:Preferences -> Editing -> Show discussion activity" users eventually. An example of this space can be seen by clicking here. The editing team has stated that this needs to be overridden on a per-wiki basis if we don't like it, I assume using MediaWiki:Common.css.

Thoughts on this change? Should we consider overriding it? I'd like to override it, personally. As a programmer it bugs me that the software is suggesting a title that isn't the "correct" title. This isn't a change we asked for. It seems confusing. Happy to hear other thoughts though. If there is consensus to change it in this discussion, I will put in an {{IAER}} to MediaWiki talk:Common.css after a couple days. Thanks. –Novem Linguae (talk) 12:44, 22 August 2023 (UTC)[reply]

It's not a space character. It's a CSS-generated gap. Copying and pasting works fine. There was a bunch of hand-wringing by a couple of editors on the phab ticket, but I haven't noticed anyone freaking out about it here. It's been deployed for a while. The weird part about it is its inconsistency: it is present in Talk pages but not here at VPT, even though the function of the colon separator is the same in both places. It should either be present everywhere or nowhere. – Jonesey95 (talk) 14:01, 22 August 2023 (UTC)[reply]
The inconsistency is exactly why we should hide it. If you were serious about making our NS-prefixed page names conform to orthography, you wouldn't do it in just a few namespaces or tweak just the heading. You would consult experts like the language committee, assess the breath and risks of the change, allocate resources, and publicize it to the communities. The fact they aren't doing that says this is an ill-conceived idea. Nardog (talk) 15:50, 22 August 2023 (UTC)[reply]
Or you could just add the CSS spacing to all namespaces and see what happens. It does not seem to have caused any harm in its beta deployment. I am frustrated by a lot of beta stuff that the WMF deploys and then leaves 80% done (cf Visual Editor, Vector 2022), but this seems like a small thing. If it causes trouble, we can remove the spacing locally, it appears. – Jonesey95 (talk) 16:01, 22 August 2023 (UTC)[reply]
Add .mw-page-title-separator { margin-right: 0.25em; } to your CSS and see how long before you have urge to write page names with the extra space or to see the rest of the interface the same way. Nardog (talk) 16:27, 22 August 2023 (UTC)[reply]
Many other editors and I have seen the spacing on talk pages for a while now. I have no such urge and have seen no evidence of such an urge. Claims that the sky is falling require evidence. – Jonesey95 (talk) 17:38, 22 August 2023 (UTC)[reply]
Agreed with @Jonesey95 that the consistency should be fixed, but otherwise it doesn't bother me. The whole concept of namespaces is one of the most confusing things about MediaWiki. This sort of helps grasp the concept because it clearly differentiates the namespace from the title. Yes, the visual spacing is jarring if you already understand namespaces, as you wouldn't type it out like that, but as it happens, it doesn't actually matter! Talk: Polar Bear still works :) That said, I do share the same concerns with @Nardog at phab:T315893#9059239 that the sake of consistency might over time might lead editors to always use spaces after colons. Before you know it, we've got yet another section added to WP:MOS, followed by tons of WP:AWB edits to make it all consistent. I don't think any of us want that, but I also think it's too early on to really say how problematic it will be. Thus far it seems to have caused few to no problems, so I'm led to believe it's one of those changes that we'll all simply get used to over time. The extra spacing bothered me when it was first deployed, but I quickly got over it, and now I even sort of like it. It's just easier on the eyes.
At any rate, we can very easily override it with sitewide CSS if needed, so I'm not really worried. I say let them upstream it to MediaWiki Core if they want – and by doing so fixing the consistency issue Jonesey95 mentioned – then we'll see how folks react. Once it effects all namespaces and all MediaWiki installations, we'll surely know if it's a problem or not. I'm aware of the issues with orthography in other languages, but here we're only debating it for English, where it doesn't seem to be that big of an issue. — MusikAnimal talk 15:54, 22 August 2023 (UTC)[reply]
I submit that "tons of WP:AWB edits to make it all consistent" are exactly what's going to happen, and what if the community says no and we have to revert the edits again? Or worse, a drawn-out RfC? I certainly don't want to see editor hours wasted like that. NL's proposed edit to the site-wide CSS is a great way to be proactive and prevent it. Nardog (talk) 16:25, 22 August 2023 (UTC)[reply]

Math parsing error

Hi, At article D-arabinitol 2-dehydrogenase, all I did was remove the Orphan tag at the article top, and now it shows in red:

Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "http://localhost:6011/en.wikipedia.org/v1/":): \rightleftharpoon</ref>

Hoping a technical expert here is able to update/fix. btw, I've never seen this before. Regards, JoeNMLC (talk) 14:47, 22 August 2023 (UTC)[reply]

Now is does not have the error, so please skip this. JoeNMLC (talk) 14:48, 22 August 2023 (UTC)[reply]
Probably relevant phab:T343648. Izno (talk) 17:10, 22 August 2023 (UTC)[reply]
For this specific case, math seems like overkill for just a single symbol that is available in plain-text (or the {{eqm}} char template if you prefer). DMacks (talk) 17:23, 22 August 2023 (UTC)[reply]
I took it (math) out as not needed. Graeme Bartlett (talk) 10:21, 24 August 2023 (UTC)[reply]

Question: Is there a tool for seeing "most-pageviews days" for an article?

We have a great tool for looking at pageviews over a given stretch of time, for example three-year pageviews of Sean Connery, but I am curious as to whether there is a way to see, for example, the top twenty individual days for pageviews for an article. BD2412 T 01:30, 23 August 2023 (UTC)[reply]

I'm not sure of such a tool but, as a workaround, it can be done by using Download > CSV on that page and then sort by the pageviews column in Excel, OpenOffice Calc or other software. Simeon (talk) 13:12, 26 August 2023 (UTC)[reply]

How to add Infobox constituency quickly?

Hi Techie, Check this link i want to add Infobox with details like name, cons No, Map, electors, current MLA etc., i have some knowledge about auto wiki browser. I cant use easily this tool. Kindly suggest any alternate tool/method available. Thanks in advance IJohnKennady (talk) 18:58, 23 August 2023 (UTC)[reply]

Teahouse

The "skip to bottom" link in the teahouse header (temporarily removed) doesn't work for me, as the anchor it links to doesn't exist. However, Esolo5002 says it works fine. Edward-Woodrow :) [talk] 21:23, 23 August 2023 (UTC)[reply]

@Edward-Woodrow: MDN states Note: You can use href="#top" or the empty fragment (href="#") to link to the top of the current page, as defined in the HTML specification. What browser are you using? It works fine for me in Firefox.
(Also: apparantly you can paste something with formatting and this'll convert it to wikitext. That's cool.) LittlePuppers (talk) 21:33, 23 August 2023 (UTC)[reply]
Firefox, and a pretty recent version thereof. Edward-Woodrow :) [talk] 21:38, 23 August 2023 (UTC)[reply]
Bah. I was looking at the link to the top. Let me look at the right one. LittlePuppers (talk) 21:39, 23 August 2023 (UTC)[reply]
I've reverted to a version with the link. Edward-Woodrow :) [talk] 21:40, 23 August 2023 (UTC)[reply]
Nope. Doesn't work. #footer-info doesn't exist. Edward-Woodrow :) [talk] 21:41, 23 August 2023 (UTC)[reply]
I see a link to #footer, which works for me; it appears that something (probably MediaWiki) adds <footer id="footer" class="mw-footer" role="contentinfo" > at the bottom of the page. What skin are you using? LittlePuppers (talk) 21:42, 23 August 2023 (UTC)[reply]
...ah, and now I was looking at the other link to the bottom. LittlePuppers (talk) 21:43, 23 August 2023 (UTC)[reply]
MonoBook. Edward-Woodrow :) [talk] 21:44, 23 August 2023 (UTC)[reply]
I switched to the tolerable version of Vector and the issue miraculously resolved itself. Edward-Woodrow :) [talk] 21:46, 23 August 2023 (UTC)[reply]
Okay... it works in every skin except Monobook. Edward-Woodrow :) [talk] 21:47, 23 August 2023 (UTC)[reply]
Okay, so I see links to the bottom using #footer, #footer-info, and #skip-to-bottom-anchor. Those appear to be in all skins, Vector (at least the tolerable version, which I also use), and {{Skip to top and bottom}}, respectively. I'd change it to #footer. LittlePuppers (talk) 21:49, 23 August 2023 (UTC)[reply]
...and #footer doesn't work in Minerva. LittlePuppers (talk) 21:52, 23 August 2023 (UTC)[reply]
The {{Skip to top and bottom}} template itself adds a <div> element with a skip-to-bottom-anchor ID. isaacl (talk) 21:55, 23 August 2023 (UTC)[reply]
Yep, and the teahouse {{skip to top and bottom}}. So I guess the best course is remove the link, unless some interface editor wants to mess around. Edward-Woodrow :) [talk] 22:09, 23 August 2023 (UTC)[reply]
Skin footer-info footer
Monobook No Yes
Vector 2010 Yes Yes
Vector 2022 Yes Yes
Minerva Yes No
Timeless Yes No

(edit conflict) Seriously? Edward-Woodrow :) [talk] 22:07, 23 August 2023 (UTC)[reply]

Wikipedia:Teahouse transcludes {{skip to top and bottom}}. Is Wikipedia:Teahouse/Header used anywhere else other than being transcluded in Wikipedia:Teahouse? isaacl (talk) 22:13, 23 August 2023 (UTC)[reply]

Teahouse-related subpages and some user sandboxes. Edward-Woodrow :) [talk] 22:14, 23 August 2023 (UTC)[reply]
I imagine "To read the newest questions, skip to bottom" isn't an appropriate message for those other locations. Perhaps add a parameter to Wikipedia:Teahouse/Header that triggers the message to be displayed, and only add the parameter setting to Wikipedia:Teahouse. isaacl (talk) 22:19, 23 August 2023 (UTC)[reply]
To make the header independent of the context in which it is transcluded, it can also position a <div> element at the bottom of the page with a specific ID and use it. But either way, the message ought to only be shown when there are questions to be read and skipping to the bottom makes sense. isaacl (talk) 22:31, 23 August 2023 (UTC)[reply]
How would the ID be positioned at the bottom of the page? Wouldn't it be easier to just insert that into the teahouse page? Edward-Woodrow :) [talk] Edward-Woodrow :) [talk] 22:33, 23 August 2023 (UTC)[reply]
The same way the {{skip to top and bottom}} template does it: use CSS style properties to position it. Yes, the Teahouse page already inserts a <div> with a specific ID that can be used, but this makes the header dependent on the Teahouse page always transcluding {{skip to top and bottom}}. I think, though, controlling the message's display is more important than making the header manage its own target ID. isaacl (talk) 22:46, 23 August 2023 (UTC)[reply]

Searching for exotic whitespace

I'd like to search for articles containing strings like "=<whitespace>http" .. where "<whitespace>" are characters listed at whitespace character (except for the normal space). For example to find "thin space", what would the search string be? I tried insource:/[=](\u2009){1,}http/ .. because the codepoint is U+2009 and according to this tutorial it might work, but does not. CirrusSearch docs has some info but nothing I can see helps. -- GreenC 01:10, 24 August 2023 (UTC)[reply]

Did you try using the actual Unicode character rather than \u2009 per the docs there? Izno (talk) 01:36, 24 August 2023 (UTC)[reply]
\u... isn't going to work. Googling "regular expression" my problem is of very limited help for Elasticsearch (which is what CirrusSearch uses as its backend); you're going to get results for the PCRE variety of regular expressions that are the de-facto standard, and the flavor Elasticsearch implements is much more limited and uses somewhat different syntax. (Upstream documentation.) Searching for the literal character, like this, gets me correct-looking results. Or, at least there was a literal thinspace in the source of the articles I spot-checked. (I was surprised that there isn't in either whitespace character nor thin space). —Cryptic 02:06, 24 August 2023 (UTC)[reply]

Quick way to move user pages in one category to another？

example: c:Category:User BG-3. i cant figure out why cat-a-lot doesnt move user pages. is there a tool to move them? RZuo (talk) 05:37, 24 August 2023 (UTC)[reply]

@RZuo, cat-a-lot doesn't work on non-mainspace pages. AFAIK, there is no replacement. — Qwerfjkltalk 15:57, 24 August 2023 (UTC)[reply]
i wanna know why. in other words, how i could tweak the code to make it move user pages too. RZuo (talk) 12:49, 25 August 2023 (UTC)[reply]
You should probably ask tech questions about Commons on Commons. They have enough savvy users there to answer. Izno (talk) 02:12, 26 August 2023 (UTC)[reply]

Odd character in cquote block

In the Sentinel program article there are a couple of quote blocks, using cquote. The second of these has an odd character at the start. This character does not seem to be in the source text. Look for "Which weapons", I see a rectangle in front of the "W". Does anyone else? Maury Markowitz (talk) 16:54, 24 August 2023 (UTC)[reply]

I have removed a stray control character.[15] It's browser-dependant what, if anything, is shown. You can copy-paste something to the "Characters" field at https://r12a.github.io/app-conversion/ (not Wikimedia affiliated) and click "View in UniView" if you want info about special characters. PrimeHunter (talk) 17:23, 24 August 2023 (UTC)[reply]

amazon kindle access

to keep this short, i am currently writing this from an amazon kindle (reading device) and attempting to access Wikipedia from it is slow, buggy,and prone to crashes, it would be awesome if this could be dealt with as soon as possible — Preceding unsigned comment added by 86.10.35.182 (talk) 21:35, 25 August 2023 (UTC)[reply]

Hyphens gadget

I'd like to have a gadget to break words with hyphens. This feature is available in CSS and it looks nice with paragraph text justification turned on. The CSS code for the gadget would look as following: 

#article, #bodyContent, #mw_content {
    hyphens: auto;
    hyphenate-limit-chars: 8 4 4;
}

The hyphenate-limit-chars option is a bit opinionated, but I've found it's a good middle-ground. Astra3 wiki (talk) 22:27, 25 August 2023 (UTC)[reply]

You may customize in your common.css user page. Izno (talk) 02:10, 26 August 2023 (UTC)[reply]

Is importScript asynchronous?

I use AutoEd with a custom set of functions in my common.js. Rather frequently AutoEd fails to run, with a warning left in my browser console along the lines of jQuery.Deferred exception: autoEdISBN is not defined ReferenceError: autoEdISBN is not defined. My suspicion is that importScript('Wikipedia:AutoEd/isbn.js') is importing the autoEdISBN function asynchronously, which creates a race condition where AutoEd might try to invoke it before it has finished importing. Is that right? And if so, is there some way to wait until importScript is finished? rblv (talk) 01:51, 26 August 2023 (UTC)[reply]

importScript is indeed async, since around a year ago I think. I think what you want is mw:ResourceLoader/Core modules#mw.loader.getScript. Izno (talk) 02:08, 26 August 2023 (UTC)[reply]
importScript has always been async. – SD0001 (talk) 08:47, 26 August 2023 (UTC)[reply]
No. It was not made async until Krinkle's adjustments last year to "undeprecate" it. This was one of the reasons it was not made a shim for mw.loader.load originally. Izno (talk) 15:42, 26 August 2023 (UTC)[reply]
That is not true, or rather – it is a myth. ImportScript was always async. It shared mostly the same code as the mw.loader family – the approach being to insert a <script> element into the page, which causes deferred loads in all browsers. But unfortunately a few users took to describing importScript as synchronous and "bad" without looking into its source code. – SD0001 (talk) 16:39, 26 August 2023 (UTC)[reply]
Thank you, mw.loader.getScript looks like what I need. Unfortunately I think there is an inherent race condition in how AutoEd handles user-defined plugins. I attempted to fix User:Rublov/common.js by using getScript to asynchronously load the AutoEd plugins, and then attaching a callback to the Promise object inside of autoEdFunctions to ensure that the code doesn't run until the scripts are loaded. AutoEd however treats autoEdFunctions as synchronous and reloads the page as soon as it returns, which is often (always?) before the async callback in autoEdFunctions has had a chance to run.
Maybe someone else has figured this out. rblv (talk) 21:23, 26 August 2023 (UTC)[reply]
Unfortunately I think there is an inherent race condition in how AutoEd handles user-defined plugins. AutoEd is ancient and I'm surprised it's maintained much less functional. I would not be surprised if there was one. Izno (talk) 21:31, 26 August 2023 (UTC)[reply]
Any suggested alternatives that are better maintained? rblv (talk) 21:41, 26 August 2023 (UTC)[reply]
Although Wikipedia:AutoEd/Customization implies the core script should be imported first, the preset files actually defer loading the core script until after the page DOM model is "ready" (however jQuery determines this). Thus I suggest structuring your common.js file to match the preset files, copying how it loads the core script (such as the code from complete.js, line 39 to line 41). I'm not sure if that's still too soon; if so, then instead of loading the core file as in line 40, you can invoke a promise like the one you have in your current common.js file, and in its callback, load the core file. This will result in a clear sequence: document ready → helper files are loaded in some order → core file is loaded. isaacl (talk) 22:06, 26 August 2023 (UTC)[reply]
Ah, I had assumed it was necessary for the core script to be loaded first. If not, then it's possible to do everything in the right sequence. Thank you! rblv (talk) 23:15, 26 August 2023 (UTC)[reply]
I looked at some of the helper files—they define standalone functions that don't use anything from the core script and don't execute any code, and I saw the preset files loaded them first which confirmed it would work in that order. You're welcome! isaacl (talk) 23:38, 26 August 2023 (UTC)[reply]

Orange bar of doom seems to be broken

Tracked in Phabricator
Task T345031

Hello, The big orange "You have new messages" bar for logged out users seems to be broken - I can't get it to disappear. I tried editing my talk page by adding a space, but all that did is change the message to "You have new messages from 2 users", even though one of the "messages" was placed by myself. 86.23.109.101 (talk) 19:25, 26 August 2023 (UTC)[reply]


i got a message on my talk page, and saw it thanks to the new notification method. however the notification can not be dismissed, liek the old orange one. this may or not be a big deal but it is something you should know about here at this noticeboard. :^) 173.87.169.10 (talk) 00:16, 27 August 2023 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1172439616"