Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VPT)
 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.

Dark mode when logged out of Wikipedia

[edit]

When logged out, in dark mode, at {{Soulfly}}, the actual link for Soulfly is an extremely dark grey that is difficult to see on a black background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 15:47, 5 September 2024 (UTC)[reply]

See the notes and linked pages from when you recently asked about this: Wikipedia:Village_pump_(technical)/Archive_214#Dark_Mode_Text. — xaosflux Talk 15:56, 5 September 2024 (UTC)[reply]
Thanks, I assume that we will have to wait our turn.
The issue is fixed when I am actually LOGGED IN, but not fixed when I am logged OUT. --Jax 0677 (talk) 16:11, 5 September 2024 (UTC)[reply]
I made this edit yesterday to improve display of self links in navboxes. I will try to fix this fully today since this specific navbox keeps coming up. Izno (talk) 16:10, 5 September 2024 (UTC)[reply]
This should be fixed for this template. Izno (talk) 17:37, 5 September 2024 (UTC)[reply]

Enhanced editnotice loader

[edit]

I worked on a module that would serve as an enhanced editnotice loader for Wikipedia. See testwiki:Module:Editnotice_load and Module:Editnotice load (which is an exact copy). Features include category editnotices, better group notices, and editnotices by page ID (which would reduce the need to move pages around).

I want to get further feedback on this loader before it inevitably gets implemented. Please check out the testwiki. It should be backwards compatible with the way we do things, but I would like checks for this first.

If this is to be implemented, there will need to be a couple of changes made, including to:

This would make the editnotice loader much more robust.

Immediately, in preparation for this, I would consider adding the following category editnotices templates:

{{BLP editintro}}

{{Disambig editintro}}

Anything else? Awesome Aasim 19:06, 9 September 2024 (UTC)[reply]

Some documentation on how it works from a user's perspective would be helpful, in order to understand the context and how it would be used in practice, including how security restrictions are enforced. On a side note, I'm not sure that its deployment is "inevitable". isaacl (talk) 22:03, 9 September 2024 (UTC)[reply]
I have some testcases on testwiki. For best results, view when logged out and inspect the HTML when logged in.
testwiki:Taylor Swift should be a good example of me getting category editnotices working. testwiki:Protected title and testwiki:Protected title2 show the protection editnotice on both the create screen and on the "does not exist" screen when a title is protected from creation for other reasons.
testwiki:Special:EditPage/A should show the page notice from testwiki:Template:Editnotices/PageID/54370 (which is for A). You can also see I renamed previous "page notice"s to "title notice"s because the way page notices are bound to currently are actually to titles, not pages. The new "page notice" will remain bound to a specific page because it uses PageID. There will be no need to update the title notices for pages that exist. On the other hand, for pages that don't exist, the title notice will need to be kept up to date. Awesome Aasim 04:01, 10 September 2024 (UTC)[reply]
I can't tell from the article page how to use the feature: where the edit notice lives, how will access be limited, and so forth. Thus it's hard to evaluate the feature without knowing the maintenance cost. isaacl (talk) 09:58, 10 September 2024 (UTC)[reply]
The editnotices live in the same pseudo-space: Template:Editnotices/. See testwiki:Module:Editnotice load/config.
I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. Awesome Aasim 13:16, 10 September 2024 (UTC)[reply]
OK, I see there's now a link above the edit notice point to its location, so category-based notices are grouped under a "Category" subpage. What are the enhancements for the group-based notices? isaacl (talk) 18:33, 10 September 2024 (UTC)[reply]
There is less ambiguity in how they are handled. For example, on testwiki:Template:A/B/C/D/E, there are five different group editnotices that can be created. So if there is a page where it is desirable that the group Template:A/B needs one group notice, and Template:A/B/C needs another group notice, and Template:A/B/D needs another group notice, that can now be done; there will be one common group notice and two separate group notices for subpages. Awesome Aasim 19:21, 11 September 2024 (UTC)[reply]
I would suggest to phase the rollout into stages, and creating a test plan to ensure nothing regressed. Editing this many interface pages and fully protected templates at once sounds like too much work for an admin to volunteer to. For instance, the specific category editnotices you mention can be left for later as we already have a decent system to handle those categories.
Immediately, in preparation for this, I would consider adding the following category editnotices templates this cannot be done immediately as they also need to be removed from Module:Mainspace editnotice, else they would show up twice when the rest of the changes are deployed. – SD0001 (talk) 08:01, 10 September 2024 (UTC)[reply]
I actually think this might be something that is better done all in one go. Removing the two category editnotices from Module:Mainspace editnotice should be kind of a no-brainer after the rollout. The way that the module currently does these checks, checking the unparsed wikitext, currently sucks.
Do you have an idea for a Scribunto test runner for Module:Editnotice load to ensure that everything works with demo editnotices? Awesome Aasim 16:53, 13 September 2024 (UTC)[reply]

I haven't noticed any bugs or regressions yet, if someone could take a second look at my code maybe then we will be able to identify potential problems. Awesome Aasim 12:52, 2 October 2024 (UTC)[reply]

Thoughts on Docbunto?

[edit]

I encountered a powerful autodoc tool on Fandom Dev Wiki called Docbunto, and I have been able to get some changes to make it work on Test Wikipedia. I think it would be very great to have an autodoc tool like Docbunto on Wikipedia to help speed up the process of writing module documentation. But the key feature I like is the ability to transclude templates and similar on Lua pages.

I don't think it is ready for English Wikipedia yet but maybe with a few changes it can be very feature rich and ready. Yeah we are not exactly a code repository, but we do have thousands of modules used across articles that would be helpful to have auto documentation for. Awesome Aasim 18:21, 17 September 2024 (UTC)[reply]

Wiktionary uses something similar. See wikt:Module:module documentation.
But the key feature I like is the ability to transclude templates and similar on Lua pages. As for this, we can already do this on this wiki: Module:Module wikitext. – SD0001 (talk) 20:15, 17 September 2024 (UTC)[reply]
Another improvement we can do over wiktionary is take advantage of line numbers now being linkable. Ideally, the generated docs of exported functions should include links to their source code definitions. – SD0001 (talk) 20:18, 17 September 2024 (UTC)[reply]
As for this, we can already do this on this wiki: Module:Module wikitext. That is very bodgy, and it doesn't entirely make sense to me how this works or why this should work. But then, an autodoc module rendering module comments is also very bodgy, although less bodgy because reading out comments to parse from the module is less likely to break than reading out variables from the documentation module after setting them in "addText". Module comments should be taken advantage of in the parser. I did open a task (and submit my first patch to MediaWiki to complete it) for having MediaWiki only parse the contents of CSS and JS comments, see phab:T373834 (and kindly do please send more feedback on how I can improve that patch!) Awesome Aasim 00:21, 18 September 2024 (UTC)[reply]
We considered generating documentation from LuaDoc when creating Scribunto, but we decided not to for the same reasons most documentation pages here are on /doc subpages instead of being inline in the template page: inlined docs can't be protected separately from the module/template and any edit to inlined docs means any pages using the module/template have to be reparsed. Anomie 23:50, 17 September 2024 (UTC)[reply]
I'd figure. I think of this inline doc as a good starting point for most Lua modules but ultimately there should be additional documentation that goes beyond the default functions and describes what the module exactly does. Awesome Aasim 23:53, 17 September 2024 (UTC)[reply]
Yeah, being able to edit documentation without going through edit requests would be nice, even though so would be autogenerating doc sections for functions. Nardog (talk) 01:20, 18 September 2024 (UTC)[reply]
Automated cat herding is not going to work at Wikipedia. Imagine forcing every module to have comments in a fixed format with extra gunk to be machine parsable. Johnuniq (talk) 02:27, 18 September 2024 (UTC)[reply]
It is really bad practice to not put comments in code. Autodoc obviously won't work if there aren't any properly formatted comments. The goal of autodoc is to document functions and variables and more importantly module exports. Even functions in use by other modules. It never is intended to replace the module documentation page at the top of each; just supplement it. Awesome Aasim 03:05, 18 September 2024 (UTC)[reply]
Yes, useful comments are great. What I meant was, it would be very difficult to get independent editors to use a fixed format. Also, I don't think documenting all functions and variables is achievable or even desirable, for example, due to the inevitable drift between hopeful comments and actual code. I do agree that exports should be documented and I once argued strongly that a module (I forget where now) should not have every function exported due to ensuing confusion and maintenance issues. I lost that argument. Johnuniq (talk) 03:34, 18 September 2024 (UTC)[reply]
There is a few related stuff I can think of.
Automatically making a list of variables is actually easy. The hard part is getting arguments in loops. See is:Module:Templatedata fyrir skriftu, which can create basic templatedata (containing only a list of variables) with the code {{#invoke:Templatedata fyrir skriftu|main|''name of module with namespace''}}.
There is also an request to WMF at meta:Community_Wishlist/Wishes/Document_ALL_the_modules! about this same subject.
Come to think of it some of doc.wikimedia.org is actually built on similar logic to docbunto. Snævar (talk) 19:08, 19 September 2024 (UTC)[reply]
Why not both? If there's comments in code formatted in a certain way, show them in /doc, but also allow overriding or appending to it without having to edit the module directly. Nardog (talk) 03:37, 18 September 2024 (UTC)[reply]
+1. I do think having both is useful. We can provide an end user overview at the top of the module documentation page, and a developer's overview in the autodoc. Something similar to how I implemented autodoc on testwiki:Module:Docbunto and testwiki:Module:i18n. There should be some sort of disclaimer that the documentation is auto generated and the contents can be overridden. Awesome Aasim 14:42, 18 September 2024 (UTC)[reply]
I did a little bit more work on the module (not really any), and I am wondering if the module can be imported from testwiki to English Wikipedia? We may have to update some of the attribution links to point to Fandom users, but not much else. Awesome Aasim 01:23, 25 September 2024 (UTC)[reply]
You are the only contributor on testwiki. Just copy it. Looks like you've modified Module:Documentation on testwiki to make it automatically show the generated docs. It may be more intuitive to not do that and instead have /doc subpages call the autodoc module (the way it's set up on wiktionary), enabling the automatic and manually written docs to co-exist, making it clearer where the autodoc came from, avoiding the weirdness of a [create] button in the documentation header showing up even when the documentation seemingly exists, etc. – SD0001 (talk) 04:13, 25 September 2024 (UTC)[reply]
But the first edit at testwiki includes an edit summary with a link to the source. That should be retained. The subsequent edits may as well also be retained in the history here. I'm still dubious about whether automatic documentation can be helpful at Wikipedia but having it here would allow live demos. Johnuniq (talk) 05:37, 25 September 2024 (UTC)[reply]
Problem: That module is at testwiki which does not appear as an option at Special:Import. Only test2wiki is available (it was added in February 2013 when Scribunto appeared here). An alternative would be for Awesome Aasim to duplicate the first edit here, with its edit summary, then make another edit to include the current version. Johnuniq (talk) 05:58, 25 September 2024 (UTC)[reply]
Yeah and there are other problems that mean it won't be ready for use right away. See testwiki:Module:Documentation's autodoc, for example.
I still managed to get it onto English Wikipedia so that we can all work together to make it robust. I actually see why the original i18n module was deleted, while the one on Fandom and on other Wikimedia projects was not: it was too simple.
I think it will require some sort of consensus to turn this on by default, but at least we have something to start. Awesome Aasim 07:00, 25 September 2024 (UTC)[reply]

So I have a question. The docbunto module I have has an option to "preface" the automatic documentation (the section between the header and the documentation of each function) with some content. Could that content potentially be the stuff transcluded on the "/doc" page? Or would it be better to not have mixing, so that the manual documentation is not overridden with the automatic documentation? Awesome Aasim 04:02, 2 October 2024 (UTC)[reply]

Making this script a gadget on enwiki

[edit]

I worked on this script years ago and it seems as if it has reached a mostly stable state. The script removes the "action=edit" from redlinks which essentially prevents the editor from auto-loading when clicking on non-existent pages that one has permission to create. I think this should be available as a gadget to allow for more configuration. Something like: Do not immediately enter editing mode when clicking on a red link.

Thoughts? Awesome Aasim 15:29, 24 September 2024 (UTC)[reply]

It's hard to see why anyone would want it, even setting aside the fact it goes through every link on the page every tenth of a second. Nardog (talk) 12:45, 25 September 2024 (UTC)[reply]
Not sure if the numbers at Wikipedia:User scripts/List are current, but if so it doesn't look like it has been picked up by many so far, so I don't expect many would opt-in. In general, we want people following a redlink to start a page. — xaosflux Talk 13:07, 25 September 2024 (UTC)[reply]
Yeah, I am aware. This is so that it picks up links in VE previews, etc. Awesome Aasim 14:12, 25 September 2024 (UTC)[reply]
@Awesome Aasim I haven't done much scripting around VE, but it seems like there should be a way to add an event listener to things like the VE preview window and only have it run when the content changes. --Ahecht (TALK
PAGE
)
14:52, 25 September 2024 (UTC)[reply]
Hmm... I am not sure... maybe someone more experienced with scripts knows... Awesome Aasim 05:55, 26 September 2024 (UTC)[reply]
You wouldn't even need that; you can just attach an onclick listener to "a.new" elements and modify the href to remove &action=edit as they're being clicked, even if they've been dynamically added after page load. Writ Keeper  06:13, 26 September 2024 (UTC)[reply]
Oh! Let me try this. One second. Awesome Aasim 06:13, 26 September 2024 (UTC)[reply]
Actually, I change my mind. Doing this would cause stuff like "open link in new tab" to not function correctly. I do hope there is something smarter. Awesome Aasim 06:15, 26 September 2024 (UTC)[reply]
No, it works with new tabs just as well as anything else:
$("#mw-content-text").on("click","a.new", function(event){
  $(this).attr("href", $(this).attr("href").replace("&action=edit", ""));
})
The URL modification happens before the click, so if you CTRL+click or whatever to open a new tab, it gets the modified URL. Writ Keeper  06:22, 26 September 2024 (UTC)[reply]
What about links that are not in mw-content-text? For example, tabs and navbars? Awesome Aasim 06:24, 26 September 2024 (UTC)[reply]
I'm not sure why you would have redlinks outside of mw-content-text, but if that were a concern, you'd just choose a node higher up than #mw-content-text. Writ Keeper  06:25, 26 September 2024 (UTC)[reply]
If a subject page has no talk page, the talk page tab appears as a redlink; similarly, if a talk page has no subject page, the subject page tab appears as a redlink. These tabs are outside mw-content-text. --Redrose64 🌹 (talk) 16:28, 26 September 2024 (UTC)[reply]

I am taking a look at the requirements at WP:GADGET and it seems to meet all of them:

  1. Gadgets must work if just included with no further configuration.: This script requires no configuration at all.
  2. Gadgets must be compatible with all major browsers, i.e., they must not terminate with errors.: Just checked. Works in both Chromium and Firefox based browsers.
  3. Gadgets should be functional in most major browsers (cross-browser compatibility). Exceptions must be clearly stated.: It is. The script works on most not all browsers. It uses the URL library which is supported by practically everyone.
  4. Duplication of gadgets should only be made if it is reasonable.: This does not apply.
  5. Collections of scripts should be split if they have disparate functions.: This does not apply.
  6. Gadgets requiring permissions must be marked and must fail gracefully if the permissions aren't present.: This requires no permissions at all as it only affects the behavior of red links.
  7. Gadgets only working in some skins must be marked as such if that data is available.: Irrelevant as it works on all skins, not just Vector and Timeless.

I don't see any requirement that the script needs to see widespread usage. I am not seeking to have this turned on by default at all. Those that want it can enable it in preferences. Awesome Aasim 18:42, 29 September 2024 (UTC)[reply]

Consider this: either it's bug reports before you turn it on or it's bug reports after. Are you planning to fix them at all? Then we just have an unmaintained gadget instead. Izno (talk) 19:31, 29 September 2024 (UTC)[reply]
The last verified bug report I received was about interwiki links being broken by my script. That was fixed thanks to work by Matma Rex which I then implemented right after. The one after that complains that "action=delete" links are being removed, which does not sound right because this only touches red links. Not enough information was given for me to figure out where this was happening.
There definitely is some room for optimizations, especially since having three instructions on one line is... not ideal. But those are formatting and style fixes, not functionality fixes. Awesome Aasim 19:52, 29 September 2024 (UTC)[reply]
I mean, personally, I wouldn't support adding a gadget that runs a javascript function ten times a second on every page on the wiki, especially for such a minor change. Writ Keeper  12:57, 2 October 2024 (UTC)[reply]
I kind of see the issue as well. The trouble is either it is run once and then it never works for when other stuff adds red links, or it is continuously updated. There is probably a way to execute this function as soon as the DOM is changed, without resorting to a thread set by setInterval. Awesome Aasim 13:02, 2 October 2024 (UTC)[reply]
MutationObserver sounds like what you want. Anomie 23:30, 2 October 2024 (UTC)[reply]
What problem does this solve? What is the problem people have with red links leading to the creation form? Nardog (talk) 13:41, 2 October 2024 (UTC)[reply]
Not everyone wants every red link to open the editor. What this would do is it would give people the option to avoid opening the editor when clicking on a red link. I do not think this should be enabled by default, but I do think it should be an option. Awesome Aasim 15:23, 2 October 2024 (UTC)[reply]

Building a simple body index calculator

[edit]

Having a discussion at this talk page to build a calculator using waist circumference and height as an index for body "roundness", which is based on eccentricity and used for anthropometric assessment in health research, first reported here.

A draft exists. Adjustments are needed to provide both metric and imperial inputs, and two decimal points, and any gadget assuring simplicity for public use. The completed calculator will be presented in the article. A commercial example is on this site.

Would be grateful for ideas and solutions. Thanks. Zefr (talk) 20:03, 25 September 2024 (UTC)[reply]

Bold solution: a zero input interface, no waist, no height to input, yet still provide the desired BRI: a table with waist left to right, height top to bottom, BRI in cells.

waist 1 waist 2 waist ...
height 1 bri w1/h1 bri w2/h1 ...
height 2 bri w1/h2 bri w2/h2 ...
... ... ... ...

Uwappa (talk) 20:20, 25 September 2024 (UTC)[reply]

Uwappa - thanks, although it isn't clear why 2 entries for waist and height are used, and the eccentricity factor is missing. Could you input data and show the result here? Also needed is the side-by-side display of metric and imperial results in 2 decimal places. See an example here (uses Wikipedia login to the medical wiki). Zefr (talk) 01:28, 26 September 2024 (UTC)[reply]
The table was based on your "using waist circumference and height as an index for body "roundness", with waist and height being the two inputs and roundess the output.
You will have far more than 2 entries for both waist and height, hence the three dots.
The MDwiki asks for weight and height, not waist and height. Never mind, the idea is still the same: no input, do all computing in advance. No threshold, no effort required from readers. I've used your link to create the numbers for the example below, which will hopefully suffice to give you an idea for a similar table with waist and height as input.
An additional idea: take it one step further and answer the question that will be in the readers mind: Am I healthy?
Colour code the background, from green for healthy, via yellow to red for dangerous. A reader could look at the row close to own height and see multiple questions answered:
  • Is my weight/waist in green, yellow or red?
  • If yellow or red, what is the green value I should aim for?
Colour codes below are not based on real data, just an example.
80 kg 90 kg ... kg
180 cm 24.7 kg/m2 27.8 kg/m2 ...
175 cm 26.1 kg/m2 29.4 kg/m2 ...
... cm ... ... ...
An even bolder proposal that will probably rock your boat, but anyway, based on your metric/imperial question: Keep the calculator for the medics and target the general audience while on Wikipedia. Boldly omit the numbers in the cells and show both metrics and imperial in row and column headers. The table will still answer the question in the readers mind: what waist/weight is healthy for me, given my height?
80 kg 90 kg ... kg
175 lbs 200 lbs ... lbs
180 cm 6 feet
175 cm ... feet
... cm ... feet
That might even allow to use both weight AND waist in the column headers and answer two questions: given my height, what weight and waist is healthy? — Preceding unsigned comment added by Uwappa (talkcontribs) 06:49, 26 September 2024 (UTC)[reply]
I am reinventing the wheel. Please look at . You could do all the computations behind it and create a similar chart for BRI. Uwappa (talk) 07:24, 26 September 2024 (UTC)[reply]
This conversation, if it is not over, should probably move to Wikipedia talk:WikiProject Medicine. It does not appear to be a technical issue. – Jonesey95 (talk) 14:18, 26 September 2024 (UTC)[reply]
I was trying to make that photo vector, but Ive gotten bored, maybe ill finish when I get around to it Anthony2106 (talk) 13:45, 28 September 2024 (UTC)[reply]
I've created one:
Graphs of BRI (coloured numbers) vs height h vs waist circumference c
cmɢʟeeτaʟκ 17:34, 29 September 2024 (UTC)[reply]
[edit]

On Wikivoyage, that article is just mediocre quality. There should be no start there. I am not sure how to remove it and what caused the error (could it happen for other articles?). Piotrus at Hanyang| reply here 04:20, 26 September 2024 (UTC)[reply]

It was added to Wikidata in this revision. Not sure why as looking through the history of wikivoyage:Kaesong it was never star quality.  novov talk edits 05:58, 26 September 2024 (UTC)[reply]
@Hanyangprofessor2: The star is because of the "badge" (a little rosette) at d:Q109079#sitelinks-wikivoyage. As noted above, this was set by Dexbot (talk · contribs) almost ten years ago; you would need to ask its botop (Ladsgroup) what the mechanism is that triggered this amendment. If it really is wrong, these "badges" appear to be user-editable. --Redrose64 🌹 (talk) 15:15, 26 September 2024 (UTC)[reply]
They aren’t; saving the changes to them is limited to certain user groups.  novov talk edits 22:59, 26 September 2024 (UTC)[reply]
@Ikan Kekek FYI, and maybe you know who to ping. Or report this to WV Traveller's Pub, I am not sure how serious this issue is, but I think the star should not be there for 'usuable' articles. Piotrus at Hanyang| reply here 07:21, 27 September 2024 (UTC)[reply]
I don't understand the problem. It's starred on Wikidata? Best to discuss that there, I guess. I don't normally edit Wikidata. You could bring this up in the voy:Wikivoyage:Travellers' pub. Ikan Kekek (talk) 15:35, 27 September 2024 (UTC)[reply]
@Hanyangprofessor2 The bot added the badge ten years ago because at least back then this revision to be exact had voy:Template:Usablecity. Note that the badge was added for "recommended article" [1] hence the silver (not gold). There are many badges. You should be able to see the list of page that have badges in voy:Special:PagesWithBadges Ladsgroupoverleg 10:26, 27 September 2024 (UTC)[reply]
And the current version of voy:Kaesong#Go next still has {{usablecity}}. This is therefore a matter for Wikivoyage, and not our problem at all. --Redrose64 🌹 (talk) 18:06, 27 September 2024 (UTC)[reply]
@Ikan Kekek @Redrose64 The issue is that usable article on Wikivoyage are just middle-level artices (see voy:Wikivoyage:Article status). A star should denote an equivalent of a Featured article - on Wikivoyage that would be a Star-class article. A Good Article equivalent there would be a Guide (which even uses the GA green cross). Having Featured Article-lookalike barnstars for Wikivoyage usable articles, which are equivalent to our B- or C- class articles, makes no sense and is arguably actively misleading. Piotrus at Hanyang| reply here 03:16, 30 September 2024 (UTC)[reply]
PS. And it is a problem for us (not for Wikivoyage), because it is us (English Wikipedia) that has misleading indicators suggesting that our sister project article is high quality, when it is not. Wikivoyage has correctly identified the article as a middle-level (usuable) article, but we are incorrectly starring them as high-level articles. Piotrus at Hanyang| reply here 03:18, 30 September 2024 (UTC)[reply]
PPS. Compare to Hiroshima, which is a star-level article on Wikivoyage, and is correctly tagged with that project's yellow star in our article. Why are we tagging Wikivoyage usable articles at all, and why are we using Featured Article symbol instead of the Wikivoyage blue circle (which is the symbol for their usable articles)? At minimum, the symbol for usable content should be fixed (from FA star to blue circle), and I'd strongly suggest removing any symbols for that class (which is below GA-level equivalent). I hope the issue is now clearer? Piotrus at Hanyang| reply here 03:21, 30 September 2024 (UTC)[reply]
@Hanyangprofessor2: The stars, discs etc. (of whatever colour) are added by mw:Extension:WikimediaBadges based on settings in Wikidata. If the extension is faulty, file a ticket at phab:. If Wikidata has the wrong settings, fix them, or find out at Wikidata why their bots are using imperfect algorithms. Whatever the problem is, it's still not our fault. --Redrose64 🌹 (talk) 20:14, 30 September 2024 (UTC)[reply]
@Redrose64 But it is our problem, and I don't have time to learn the extension details to fix it. I am just reporting it here, so those more familiar with the issue can investigate it and fix it.
I will ping editors who have edited the mediawiki extension page you linked: @MarcoAurelio @Eisheeta Piotrus at Hanyang| reply here 06:53, 2 October 2024 (UTC)[reply]
@Hanyangprofessor2: How can it be out problem when (a) there is no fault at English Wikipedia and (b) there is nothing that can be done at English Wikipedia to alter the situation? As for MarcoAurelio and Eisheeta, they will probably tell you exactly what I have already said: that the extension displays a star according to whatever is set on Wikidata. Have you raised any discussions at either Wikidata itself, or at Wikivoyage? --Redrose64 🌹 (talk) 09:47, 2 October 2024 (UTC)[reply]
@Redrose64 It is our problem because we are displaying misleading information to our readers. I am not saying it is our fault, I am not saying it is anyone's fault (we are all well meaning volunteers here), but it is not Wikivoyage of Wikidata problem, because the error (which may be related to some bad tool they use or used) affects us, not them. And as I said, I don't know where else to raise this problem, and it is us who should care the most about it, since we (our readers) are the ones most affected. Piotrus at Hanyang| reply here 07:34, 3 October 2024 (UTC)[reply]
(edit conflict) @Hanyangprofessor2: Two users above have suggested voy:Wikivoyage:Travellers' pub; you have posted there before regarding other matters, so you are aware of its existence. Then there is d:Wikidata:Project chat. Now please stop pretending that this is an English Wikipedia problem when all we are doing is reflecting data that is stored elsewhere. This is like reading in your newspaper about some unpleasant situation in a foreign country and expecting your local newsagent to do something about it. --Redrose64 🌹 (talk) 16:15, 3 October 2024 (UTC)[reply]
As I explained to you, I don't believe it is Wikivoyage problem at all. Wikidata, to a small degree (because some data is hosted there). But this is primarily our problem; it doesn't matter where the data is stored - it is our project which displays misleading information. I do not understand why you are fine with our website displaying errors. Piotrus at Hanyang| reply here 03:57, 4 October 2024 (UTC)[reply]
Our website displays millions of errors. This is a tiny minor detail that in no way compromises the integrity of English Wikipedia. To quote Jonesey95: The problem is that a silver star is used for both "Good" (second-tier) and "Recommended" (i.e. third-tier, the level below Good quality) in the extension. Please note those words in the extension. Nothing that Jonesey95 has written demonstrates that it is our problem at all. Jonesey95 has restated - in different words - information that was already provided to you earlier in this thread. Sure, we display that little silver star. But the code to display that star is part of the MediaWiki software, which is shared by all WMF wikis. --Redrose64 🌹 (talk) 07:34, 4 October 2024 (UTC)[reply]
Feel free to disagree, but I believe that removing even one error is a good thing. I don't feel that the fact that our website has millions of errors is ok. Piotrus at Hanyang| reply here 03:06, 5 October 2024 (UTC)[reply]

I did a bunch of digging to see what might be happening here. So far I have found a page explaining that on en.WikiVoyage, they have Star (=en.WP FA), Guide (=en.WP GA) and Usable (no en.WP equivalent?) articles. Then I found this October 2014 bot request on Wikidata listing those same three article statuses and asking for Dexbot to assign badges based on those statuses. The bot's edit adding the "recommended article" status for en.Wikivoyage to Kaesong on Wikidata happened in that same time frame. So far, it appears that everything is working as designed. Then I found this CSS page, part of the mw:Extension:WikimediaBadges extension, that assigns star images. It assigns a gold star to Featured articles, and a silver star to articles flagged with either "goodarticle" or "recommendedarticle" status.

As far as I know, en.WP does not have a "recommended article" status (I'm not seeing anything comparable in the table at {{Article history}}).

TL;DR: The "recommended" (i.e. third-tier) tag next to en.Wikivoyage on Kaesong on Wikidata appears to be correct, according to the statuses used on en.Wikivoyage. The problem is that a silver star is used for both "Good" (second-tier) and "Recommended" (i.e. third-tier, the level below Good quality) in the extension.

It seems to me that if a "recommended article" is a third tier, it should get a bronze star (to be in line with gold and silver). That might mess up the star color on other WMF wikis, though. Since the extension is not documented well (see T212020), and I haven't found a table or map that shows the different statuses on each monitored site, it is difficult to know whether changing "recommended article" to bronze in the CSS file would fix a problem here but break something on another site. – Jonesey95 (talk) 16:07, 3 October 2024 (UTC)[reply]

It turns out that there is an existing Phabricator feature request at T189374 to make this change. If anyone here wants to make this change happen and knows how to actually upload a proposed change to gerrit/github or whatever site is used, be my guest. – Jonesey95 (talk) 16:24, 3 October 2024 (UTC)[reply]
Pinging Krinkle and Ladsgroup, who have contributed code to this extension. – Jonesey95 (talk) 16:29, 3 October 2024 (UTC)[reply]
Badges to my knowledge are owned by WMDE. Please contact wikidata team. Ladsgroupoverleg 18:01, 3 October 2024 (UTC)[reply]
How? A link to the appropriate discussion page would be helpful. I find Wikidata impenetrable. – Jonesey95 (talk) 21:09, 3 October 2024 (UTC)[reply]
@Jonesey95: d:Wikidata:Project chat, as I mentioned earlier. --Redrose64 🌹 (talk) 22:50, 3 October 2024 (UTC)[reply]
Thanks. I have posted there. We'll see if anyone is able to help from there. – Jonesey95 (talk) 23:33, 3 October 2024 (UTC)[reply]
@Jonesey95 Thank you for investigating it and trying to actually help, rather than brushing this off. I expect some readers of English Wikipedia are confused, but they likely don't even know (or care enough) to report this. Piotrus at Hanyang| reply here 03:55, 4 October 2024 (UTC)[reply]
  • Do any of the regular (or irregular) watchers at VPT feel that this is an English Wikipedia problem? Or that it is not? Please state one way or the other. --Redrose64 🌹 (talk) 07:53, 4 October 2024 (UTC)[reply]
    It's an en.WP problem in that we are affected by it. If my neighbor's car alarm is going off in the middle of the night, it's a problem for me in that I can't sleep, and it's a problem for my spouse in that my spouse has to listen to me complain about it. I would not be surprised if other WMF sites are affected by this doubling-up of second-tier and third-tier article quality indicators; if so, it is a problem on many sites. The origin of the problem appears to be in a Wikimedia (or WMDE, whatever the difference is) extension. Problems that manifest on en.WP are often caused by code that is outside of our immediate control. – Jonesey95 (talk) 12:45, 4 October 2024 (UTC)[reply]
    I don't see a star at all, even if I log out and view with a majority desktop browser, or go into mobile mode. Does it need a gadget or preference enabled to see, or am I just missing it? But I agree with Jonesey95 that it's our problem if it's displaying on our site; and we should fix it locally if a global fix is impractical or undesirable. —Cryptic 13:22, 4 October 2024 (UTC)[reply]
    so you can either get some earplugs (fix locally) but this just masks the problem, it doesn't make it go away. Or, you go round to your neighbour, tell them they have a problem with their car and ask them to fix their car (global fix). Here, we should be going to the neighbour. Nthep (talk) 14:10, 4 October 2024 (UTC)[reply]
    Yes, getting your neighbour to fix it is best, but if the alarm keeps going off night after night, you wear earplugs in the meantime. —Cryptic 15:16, 4 October 2024 (UTC)[reply]
    The trouble is, we forget to remove the earplugs after the neighbour fixes the car. Nthep (talk) 17:48, 4 October 2024 (UTC)[reply]
    The stars are not visible in Vector 2022 due to a bug. Try forcing Vector Legacy: https://en.wikipedia.org/wiki/Kaesong?useskin=vector and note the silver star next to WikiVoyage in the left-side menus, under "In other projects". That silver star should be bronze, because Kaesong is a "Usable" (third-tier) article on WikiVoyage. This is admittedly a trivial matter, but we are at VPT .... – Jonesey95 (talk) 15:10, 4 October 2024 (UTC)[reply]
    Thank you. .badge-recommendedarticle.badge-recommendedarticle { list-style-image: url(https://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/Rekommenderad_gr%C3%B6n.svg/12px-Rekommenderad_gr%C3%B6n.svg.png); } in your CSS changes it to the green star from the phab ticket. Obviously that isn't usable sitewide as-is - the file needs to be protected, it should be uploaded at the proper size instead of relying on the scaled-down version which will eventually go away, and like you say above bronze is probably a better choice - but it's enough to show we don't have to wait on an upstream fix, which may or may not ever happen. —Cryptic 16:19, 4 October 2024 (UTC)[reply]

Turning on the Calculator gadget as default

[edit]

As a continuation of this discussion Wikipedia:Village_pump_(technical)/Archive_215#New_gadget_for_doing_user_entered_calculations, I would like to see this gadget turned on by default for pages in the Category:Pages using gadget Calculator. Any concerns? Doc James (talk · contribs · email) 18:32, 26 September 2024 (UTC)[reply]

See this in action on an article using this special url: https://en.wikipedia.org/wiki/Body_roundness_index?withgadget=calculatorxaosflux Talk 20:01, 26 September 2024 (UTC)[reply]
Some feedback:
  • As currently written this won't work in the official Wikipedia mobile apps or for anyone with JavaScript disabled or an older browser. This needs better fallback behaviour in my opinion before being enabled. [1] FWIW viewing it without the gadget I thought the page was broken and went to edit it.
  • It seems to print NaN if I enter a waist figure but no height - this seems like a basic error that should be fixed.
  • Switching between metric and imperial loses the form values - this doesn't seem like a very good user experience.
  • Perhaps there should be a clearer way to report bugs and some more context explaining it - that might be a case of simply adding a caption.
Hope this is helpful.
[1] Note that anything that uses a template gadget will not work for anyone consuming our content outside English Wikipedia so that's something to bear in mind e.g. Wikiwand, apps, Google etc.. . At minimum I think this should provide some error message saying "This interactive element is not supported by your device." 🐸 Jdlrobson (talk) 00:44, 27 September 2024 (UTC)[reply]
Excellent points Jdlrobson. Will work on building some of these. Doc James (talk · contribs · email) 02:49, 27 September 2024 (UTC)[reply]
Most of that is already supported by the gadget, but needed some small changes to the specific wikipage template to work. [2]. Bawolff (talk) 03:41, 27 September 2024 (UTC)[reply]
User:Jdlrobson does this address your concerns? Doc James (talk · contribs · email) 03:49, 27 September 2024 (UTC)[reply]
A few more thoughts - again hope this is helpful!
  • When I disable JavaScript the box is empty - there is no message explaining I am not seeing something. Is that intentional? screenshot.
  • I looks like when tabbing through the page, you tab through the widget form as well. This makes it harder to tab to the actual readable content. You could add a tabindex=-1 to remove it from the tab order or make sure editors know to mark the lead paragraph before the infobox (this is not a problem on mobile where the lead paragraph gets moved as a workaround for this very big issue).
  • I'm not a designer (FWIW I think this would benefit from some design input) but, in this case, I feel like a call to action button here that loads the widget would be more effective e.g. "Learn what your own body roundness index is!" that when clicked loaded the form. I imagine such a call to action could be generalized in a template which has information on how to load itself. This would also reduce the amount of bytes we add to the page as you could load the code on demand.
Getting back to your original question about making this default: I do think you might have an easier time if you could ground this decision in data. I think (at least initially) it would be a good idea to instrument this using the statsv increment interface to get an idea of usage and confirm your hypothesis that users will interact with such widgets on a page - counting page views and some kind of interaction (e.g. typing a number in one of the boxes) and comparing the two values. If enabling this gadget was conditional on that data:
  • what would success look like? 10% of people who read the page interact? 1%? 0.1%?
  • Under what circumstances would you consider it a failure?
I think too often we (Wikipedia) enable default experiences via gadgets without inspecting our own biases about what is useful and what isn't and framing it in this way may provide a model for success in future experiments and existing features.
Best of luck! 🐸 Jdlrobson (talk) 02:05, 1 October 2024 (UTC)[reply]
Yes, the box being empty is intentional. Users can add custom fallback text at the template level, but the initial thought was that this is an enhancement to the article but not core content. Its unlikely a user on the app or without javascript is going to change just to view the calculator, so better to just have nothing if we can't show the calculator. In regards to tabbing, I would be concerned that disabling tabbing might have a negative impact on accessibility. Statistics is probably a good idea. I'm a bit nervous though that statsv is being deprecated and its a bit unclear what is happening here medium term (phab:T355837), however presumably there will be some replacement and possibly it will be transparent (for reference, mostly for myself as it was hard to find, i think mw:Gadget kitchen: recording metrics is the appropriate doc) [Edit: Also the rules around what data collection is acceptable are a bit ambiguous. I guess here we would want to track if a user interacted with the gadget on a specific page] Bawolff (talk) 05:02, 1 October 2024 (UTC)[reply]
We certainly have a lower bar for default gadgets that are also using category triggers than ones that are not. Default is really the only way to bring category triggered gadgets to readers. We don't have that many yet, so currently don't hide them allowing for opt-out. — xaosflux Talk 15:39, 2 October 2024 (UTC)[reply]
I noticed that on Firefox (version 130, x64 Linux) the width of the number inputs doesn't seem to account for the stepper arrows, causing e.g. a three-digit height (metric) on Body roundness index to be cut off on all desktop skins except Timeless. Rummskartoffel 09:14, 29 September 2024 (UTC)[reply]
Will take a look when I have a machine I can run Firefox on... Doc James (talk · contribs · email) 14:35, 29 September 2024 (UTC)[reply]
The fact that it differs between skins suggests to me it might be related to which font is used. Bawolff (talk) 20:31, 29 September 2024 (UTC)[reply]
After looking more carefully, it seems like the difference is that timeless uses 15px font vs vector using 13.3px font. This adjusts the size of the input box to be different, but on firefox it appears that the number selector is a more constant size regardless of font (vs chrome where the selector only appears on hover). Bawolff (talk) 03:04, 30 September 2024 (UTC)[reply]

Village pump permalinks?

[edit]

Is there a way to provide a permalink to Village pump topics which will survive the topic being archived? Thisisnotatest (talk) 00:14, 28 September 2024 (UTC)[reply]

Permalinks always survive archiving, as they are links to a specific revision, for example this this is the permalink to the revision prior to my response. — xaosflux Talk 00:24, 28 September 2024 (UTC)[reply]
This question actually calls out one of the problems with organization of talk pages and any other kind of page that effectively tries to track multiple topics on a single page, particularly when they are used for the purpose of "cases" which have their own individual "lives". When you get a permalink, that lets you view the state of the page at some point in time. So if you get a permalink for such a page at some instant in time, you can see the case of interest at that point in time. You can link forward to the following version of that page, but there may have been no change to the case you're interested in. You might need to go through large numbers of versions for which the case you're interested in hasn't change. To find it just before it got migrated to an archive could have involved hundreds of versions. Of course, you can check the archive, but there could have been versions where content which was added but subsequently deleted, so you wind up having to look at numerous versions that did not affect the topic you're interested in. This is just an inherent limitation of the way that talk pages are managed. — Preceding unsigned comment added by Fabrickator (talkcontribs) 00:42, 28 September 2024 (UTC)<diff>[reply]
Confirmed. I'm looking for a link which will always link to the current state of the topic without regard to whether the topic has been archived or had subsequent updates. Thisisnotatest (talk) 02:45, 28 September 2024 (UTC)[reply]
@Thisisnotatest: It is presently in place, but relies on several factors. First, people must always make links to the thread using normal Wikilinks (i.e. [[Wikipedia:Village pump (technical)#Village pump permalinks?]]) and not external links (i.e. [https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Village_pump_permalinks%3F]), regardless of the page where those links are made. Second, the VP page must be set up for archiving by ClueBot III (talk · contribs) (this is the case for WP:VPM and WP:VPW but not for VPI, VPP, VPR or VPT which all use lowercase sigmabot III). Third, other forms of archiving (whether manual, script or bot) must not be used on the VP page. If all of these are observed, ClueBot III will fix inward links to threads as and when they are archived, see for example these edits. --Redrose64 🌹 (talk) 10:02, 28 September 2024 (UTC)[reply]
@Redrose64: Thank you! Thisisnotatest (talk) 23:06, 28 September 2024 (UTC)[reply]
If you click on the timestamp for any comment, such as the first comment in a section, a link to that comment will be copied to the clipboard. When in future this section is archived, then when the link is followed, MediaWiki will display a popup message, with a link to the new location of the comment in the archive. See mw:Help:DiscussionTools § Talk pages permalinking for more details. (If you would like the link in wikitext format rather than an URL, you can try my user script to copy comment links to the clipboard to save you the work of adjusting the URL.) isaacl (talk) 05:02, 28 September 2024 (UTC)[reply]
@Isaacl: Thank you, that's perfect, especially as I would ususally be linking to my first comment. Thisisnotatest (talk) 06:04, 28 September 2024 (UTC)[reply]
Keep in mind, those such links are much more fragile than actual permalinks. — xaosflux Talk 09:50, 28 September 2024 (UTC)[reply]
It's a tradeoff. A link to an actual page version won't get affected by subsequent edits, while the new talk page comment permalink feature relies on the content not being deleted without being moved, and the relevant signatures not being modified, to gain the benefit of linking to a specific comment with later responses also being shown. isaacl (talk) 17:24, 28 September 2024 (UTC)[reply]
Not much more fragile, and there's the very useful benefit over linking to the revision of being able to see the responses.
It's actually possible to make a permalink to a comment that doesn't rely on the "visit the page and see the popup banner if the topic has been archived" behavior: the pages Special:FindComment and Special:GoToComment exist and facilitate this. E.g. this is a link to this topic that will always immediately redirect to wherever it currently lives.
(@Isaacl if you wanted to use these in your above-mentioned script, feel free -- they should be stable. You just need the ID from the fragment of the link you copy via the timestamp.) DLynch (WMF) (talk) 19:35, 2 October 2024 (UTC)[reply]
Thanks for the info! I'll give it some thought. On the one hand, I like having the original page name in the link, so those who can see the link by hovering will get a quick preview of where the link is going. On the other hand, skipping the popup banner is great for getting right to where you want to go. isaacl (talk) 21:09, 2 October 2024 (UTC)[reply]
I've updated my script to generate a Special:GoToComment permalink and copy it to the clipboard. I'm actually retrieving the IDs from the <span> elements with a data-mw-comment-start attribute. There is a <span data-mw-comment-start id="...">...</span> element nested within the <h2> element for the heading; is this something intended to provide permalinks to section headers? It seems to work with the Special:GoToComment page. isaacl (talk) 22:03, 2 October 2024 (UTC)[reply]
Yeah, if you're already looking at the data in the DOM then you might as well use the header ID. It's slightly less reliable, because it doesn't include the username of the person who posted it, so it's technically more possible to have a collision where the exact same heading is posted at the exact same moment on multiple pages.
The main practical difference for you might be aesthetic -- the highlight when you follow the link winding up on the heading versus on the entire first comment. DLynch (WMF) (talk) 22:28, 2 October 2024 (UTC)[reply]
So far I've used either the link to an individual comment, or the link to the header using the table of contents ID (which my script also provides a quick way to copy in wikilink format). I didn't really know what to make of the ID that I asked you about. Thanks for the info about it! isaacl (talk) 22:54, 2 October 2024 (UTC)[reply]

NewUsers now blue-linking everyone’s contribs pages

[edit]

iOS Safari browser: NewUsers seems to have recently had a change so that all users’ contribs pages are blue-linked, whether they’ve made an edit or not. I foresee this increasing UAA reports that get a Wait until the user edits. response. Is there a way to get around this? MM (Give me info.) (Victories) 14:45, 28 September 2024 (UTC)[reply]

Can you be more specific about the page you are referring to? the user creation log doesn't seem to be doing this in a couple of different views I tried. — xaosflux Talk 15:05, 28 September 2024 (UTC)[reply]
Okay, for example.

16:22, 28 September 2024 User account Karen8907 talk contribs was created

’contribs’ used to be red, if the user had made no edits. Now they are all blue, whether there’s an edit or not. Does that make more sense?
I have ‘advanced mode’ on. Is that likely to be anything to do with it? MM (Give me info.) (Victories) 15:24, 28 September 2024 (UTC)[reply]
When logged out, at mobile view, I only see blue contribs links; at desktop view most are red. So "advanced mode" (whatever this is) is not a factor. --Redrose64 🌹 (talk) 16:02, 28 September 2024 (UTC)[reply]
If the user has no edits then the contribs link has the class mw-usertoollinks-contribs-no-edits in both desktop (tested in Vector legacy) and mobile, but only desktop has this CSS:
.mw-usertoollinks-contribs-no-edits {
  color: #ba0000;
}
You can add the following to your CSS to get red links in all skins assuming they add the class:
.mw-usertoollinks-contribs-no-edits {
  color: #ba0000 !important;
}
PrimeHunter (talk) 16:36, 28 September 2024 (UTC)[reply]
Code’s done the trick. BigThank, Prime. MM (Give me info.) (Victories) 16:57, 28 September 2024 (UTC)[reply]
WMF recently changed link colors on Minerva and I suspect this is another casualty (or was a delta that always existed and shouldn't have). @Jon (WMF) Izno (talk) 16:48, 28 September 2024 (UTC)[reply]
Just as a heads up, my skin is Vector (2022), not MinervaNeue. MM (Give me info.) (Victories) 16:59, 28 September 2024 (UTC)[reply]
You linked the mobile site above and claimed to be on iOS. You cannot today select a skin for mobile website: you are always on Minerva. Izno (talk) 17:08, 28 September 2024 (UTC)[reply]
It was xaosflux who linked mobile but MM is probably there. "Advanced mode" is a feature of the mobile version at https://en.m.wikipedia.org/wiki/Special:MobileOptions. Mobile devices usually pick the mobile version by default regardless of your skin. You can switch at "Desktop" or "Mobile view" at the bottom of pages. If it says "Desktop" then you are currently on mobile, also called Minerva. PrimeHunter (talk) 17:15, 28 September 2024 (UTC)[reply]
Yeah, they really need to fix all those new link bugs. QuicoleJR (talk) 13:23, 29 September 2024 (UTC)[reply]

And indeed, the CSS that should be activating is

.mw-usertoollinks-contribs-no-edits {
  color: var(--color-destructive,#d73333);
}

And which is instead being overridden by

a:not([role="button"]):not(.minerva__tab-text) {
  color: var(--color-progressive,#36c);
  border-radius: 2px;
  text-decoration: none;
}

likely due to specificity, since :not() adds to the specificity. Izno (talk) 17:11, 28 September 2024 (UTC)[reply]

@Izno You are correct, those styles were the cause of this issue. We've updated those styles last Friday and we'll be deploying the fix this week. EDIT: I spoke too soon, that update did not fix the issue. I've captured this in a Pabricator task: [Minerva] Users lists show blue "contribs" link for users with no contributions and we're working on a fix. JDrewniak (WMF) (talk) 22:04, 30 September 2024 (UTC)[reply]

Preview box

[edit]

The yellow box that says This is only a preview; your changes have not yet been saved! when you preview your edit doesn't seem to be showing up for me. Instead, the message is just shown in plain text under the "Preview" header, which makes it seem like it is part of the actual text. Was this an intentional change? The box appears normally when signed out. InfiniteNexus (talk) 18:52, 28 September 2024 (UTC)[reply]

 Works for me What is your skin and browser? --Redrose64 🌹 (talk) 20:26, 28 September 2024 (UTC)[reply]
Vector 2010 on Chrome. But I get the same result when I try switching to Vector 2022 and Firefox. InfiniteNexus (talk) 06:46, 29 September 2024 (UTC)[reply]
Are you using the non-default live preview feature? If so there is a fix on the current train (I do not have the bug handy). 🐸 Jdlrobson (talk) 18:42, 1 October 2024 (UTC)[reply]
I'm not sure what exactly you're referring to, but I think I've identified the issue. When I uncheck "Show preview without reloading the page" in Special:Preferences, the box appears as normal. Turn it back on, and the box disappears. InfiniteNexus (talk) 07:22, 2 October 2024 (UTC)[reply]

Earwigs copyvio tool is down

[edit]

What it says on the tin. The Earwig is aware of this. Whenever anyone tries to use the tool, they get this message most of the time: An error occurred while using the search engine (Google Error: HTTP Error 429: Too Many Requests). Note: there is a daily limit on the number of search queries the tool is allowed to make. You may repeat the check without using the search engine.

Obviously, there's a bit of tomfoolery around hitting the limit, which is apparently shared by all users of Wikipedia. There was some discussion in the WMF section of the pump a few weeks back about what the WMF can do about it. I'm mostly interested in what we can do in the meantime while it gets fixed. I dream of horses (Hoofprints) (Neigh at me) 00:56, 29 September 2024 (UTC)[reply]

You could do your own search engine search for snippets of text from the article. One sentence from each paragraph should give an indication of problems. And you can tick the box on the tool to limit the check. Graeme Bartlett (talk) 05:49, 29 September 2024 (UTC)[reply]
This is the message I get every time I try to use Earwig check tool since early 2024. It's always over the limit. I've asked Earwig about it multiple times and I think the problem is that bots can use it and they are causing it to hit its daily limit pretty early in the day. I wish bots could get booted of so that regular editors would have access to the tool but I have yet to see any change. I don't even try to use it any more. Liz Read! Talk! 22:43, 29 September 2024 (UTC)[reply]
It does work for me quite often, probably as I am in a different time zone. You may have to await the end of the "day", and try again. Graeme Bartlett (talk) 22:47, 29 September 2024 (UTC)[reply]
@Liz: There's a message from Chlod saying The Right People are aware and working on a way to authenticate. I'm sure that'll boot the bots off.
@Graeme Bartlett: I was thinking more of an alternative tool that we can use instead? Like, how does CopyPatrol work? I dream of horses (Hoofprints) (Neigh at me) 04:57, 2 October 2024 (UTC)[reply]
Perhaps the bot behind this tool is what is exhausting Google? I don't know/ https://meta.wikimedia.org/wiki/CopyPatrol It also uses turnitin, and you can tick that box on earwig. But its findings show less than Google search. Graeme Bartlett (talk) 06:07, 2 October 2024 (UTC)[reply]
There is some documentation that indicates that a bot is going through recent changes and marking the likely copyright cases to copypatrol. Looking at a single page, surfacing results for that page like that is less traffic than letting several users query that same page. I would say Copypatrol should be used for english wikipedia and other supported projects, but earwigs tool when copypatrol does not support the project. Snævar (talk) 01:15, 3 October 2024 (UTC)[reply]
@Graeme Bartlett and @Snævar: CopyPatrol uses TurnItIn, not google (unlike Earwig, which uses both Google and TurnItIn). Probably why it shows less (which is a bit of a problem), but perhaps it is a stop gap measure. My main concern about CopyPatrol is that it's more useful for individual edits and not an entire article. I dream of horses (Hoofprints) (Neigh at me) 22:07, 3 October 2024 (UTC)[reply]
[edit]

I was doing some cleanup on Lockheed Martin shooting and came across an situation that I have never encountered before. The Internet Archive links at least on this article now seem to be failing. When I went to the saved URLs, the content that had been saved in the past came up in passing but then a different link/usurped content? for widgetbox(dot)com came up/took over. Has anyone else come across a similar issue? Is this just The Meridian Star news articles? And hey, for any of the lurkers around here who knows what's what etc, apologies in advance if I've possibly posted this issue in the wrong place, I just couldn't figure out where this might belong. No snark please, I just figured I better ask somewhere around here. - Thanks, Shearonink (talk) 18:02, 29 September 2024 (UTC)[reply]

Shearonink, are you referring to this? — Qwerfjkltalk 19:51, 29 September 2024 (UTC)[reply]
A couple of things happen.
When I click though the link that you posted above I get a result saying the "page doesn't exist..."
BUT when I click on Ref #7/"Three years later" in the Lockheed Martin shooting from the Meridian Star ->>https://web.archive.org/web/20120314014942/http://meridianstar.com/local/x681061768/Lockheed-Martin-Three-years-later?keyword=leadpicturestory I get THIS wacky "widgetserver" result-->>>https://web.archive.org/web/20120327105127/http://cdn.widgetserver.com/
Hope i've explained it...I'm kind of flummoxed by all this. I even tried to do a search for both of the Meridian Star articles at Newspapers.com and also at the paper's website but couldn't get any results. - Shearonink (talk) 22:04, 29 September 2024 (UTC)[reply]
Looks like a widget that the page included forces a redirect for some reason. Anyway I've changed the reference to use an archive from a different date, that doesn't seem to have that issue. --Chris 08:22, 30 September 2024 (UTC)[reply]
Thanks Chris G. I had never seen a redirect like that, basically hidden within a webarchive URL. Seems like a usurpation... I'll remove the dead link template. I was vaguely thinking it had something to do with recent news about the Wayback Machine being sued?... - Shearonink (talk) 14:33, 30 September 2024 (UTC)[reply]
Wayback Machine itself @Shearoninkwas not relevant in the lawsuit. Rather Internet Archive was sued for its book lending program, so completely unrelated. Based on above discussions, rate limits are issue with Google itself. ~ 🦝 Shushugah (he/him • talk) 22:12, 3 October 2024 (UTC)[reply]
[edit]

"Related changes" seems to be broken. I usually view CAT:RFU using RelatedChanges, like this. I'm only getting the current day's changes. This is new as of today. --jpgordon𝄢𝄆𝄐𝄇 18:12, 29 September 2024 (UTC)[reply]

I see entries since 22 September. The top right has a box saying "500 changes, 7 days" for me. Do you have such a box, what does it say and can you change it? PrimeHunter (talk) 20:22, 29 September 2024 (UTC)[reply]
It appears to have resolved itself. --jpgordon𝄢𝄆𝄐𝄇 14:50, 30 September 2024 (UTC)[reply]

Italic title doesn't work on Mickey Maguire (Shameless), DISPLAYTITLE does

[edit]

This version of Mickey Maguire (Shameless) uses {{italic title}}, and complains about no matching string. I couldn't find any invisible characters, so I'm out of ideas. Paradoctor (talk) 18:24, 29 September 2024 (UTC)[reply]

{{italic title}} omits italics in parentheses, also when |string= is used. I think it should be changed but that's how it works now. {{Italic disambiguation}} can be used for your purpose without parameters. PrimeHunter (talk) 20:13, 29 September 2024 (UTC)[reply]
Alternatively, changing the page title to the more general disambiguation of "character" removes the need for italics in the title. Izno (talk) 20:28, 29 September 2024 (UTC)[reply]
D'oh! I just realized that I should've used |all=yes.
Of course, {{italic disambiguation}} is easier, so I'll use that. Thanks. Paradoctor (talk) 20:45, 29 September 2024 (UTC)[reply]
Resolved

Quarry down?

[edit]

Hello, Tech aficianados,

I know that this area technically isn't in Wikipedia's realm of control but I was just wondering if anyone knew why Quarry was down. I can't get any of my regular pages to even load. And, unfortunately, Phab isn't accepting the password I typically use and I don't want to reset it until the end of the day so I can't file a bug report. But I did a search and I can't see that anyone else has filed a ticket either.

The message I get is a logo for Wikimedia Cloud Services and then:

  • Error
  • This web service cannot be reached. Please contact a maintainer of this project.
  • Maintainers can find troubleshooting instructions from our documentation on Wikitech.

I tried to find a discussion page at MediaWiki but was unsuccessful. Any clues? If the cloud services are down, it seems like it would be affecting other aspects of this project but I'm just running into problems with Quarry. Thank you. Liz Read! Talk! 22:48, 29 September 2024 (UTC)[reply]

@Taavi: could this be related to the changes from phab:T361471? – 2804:F14:80A0:C01:CAC:C72A:E92:375B (talk) 01:05, 30 September 2024 (UTC)[reply]
Thanks for supplying this. But it's from months ago so I'm not sure if it is relevant for today's problem. Quarry gets a lot of use though so I'm surprised there isn't an open ticket. But I appreciate you looking for one that is related. Liz Read! Talk! 02:58, 30 September 2024 (UTC)[reply]
The change they did to fix this issue was applied on the 25th of this month, that's why I thought it might be related. At any rate Taavi is the one who made that fix, so he would know for certain - and probably can offer some information about the current problem too. – 2804:F1...92:375B (talk) 03:43, 30 September 2024 (UTC)[reply]
I finally got the right password and filed a ticket. No response yet. Liz Read! Talk! 05:24, 30 September 2024 (UTC)[reply]
Most likely unrelated. Taavi (talk!) 07:55, 30 September 2024 (UTC)[reply]
Should be back up and running, not sure yet why it failed, investigating in phab:T375997. DCaro (WMF) (talk) 08:03, 30 September 2024 (UTC)[reply]
Thanks for checking on this, Taavi and DCaro (WMF). Liz Read! Talk! 21:27, 30 September 2024 (UTC)[reply]

Can't close maps (firefox 130, Windows 10)

[edit]

Hi everyone, recently I've been having an issue where I can't close fullscreen maps when I click them in articles. Any ideas? I can't click the cross and can't use escape, literally the only way to get back to the article is to refresh it. Tested on firefox safe mode without extensions. It works fine on Chrome. And Also, I can close maps on Wikivoyage, specifically GPX maps, instead of GeoJSON as on Wikipedia. </MarkiPoli> <talk /><cont /> 13:25, 30 September 2024 (UTC)[reply]

I've noticed this occasionally in Chrome as well, but have never found a consistent way to reproduce it. the wub "?!" 11:59, 1 October 2024 (UTC)[reply]
I think I've found it (or one of them at least):
  • Click on an image, which launches the Media Viewer
  • View the next or previous image by clicking "<" or ">"
  • Close the Media Viewer
  • Open a map
  • You can't close the map
Nardog (talk) 18:57, 1 October 2024 (UTC)[reply]
Which article did you use to do these steps? I was able to reproduce these steps (only on Firefox, *not Chrome) in the article Brooklyn Bridge, I didn't even need the second step. Though the bug only happens if I haven't opened the map and closed it before opening an image. – 2804:F1...ED:16CD (talk) 02:43, 2 October 2024 (UTC) *edited 03:48, 2 October 2024 (UTC)[reply]
I've investigated some (I say some because this seems more of an overview of the cause, though I witnessed it happening with the browser's debugger):
  1. The Media Viewer extension adds a new route handler for what function to call when the page navigates to an empty hash like //en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#
  2. Unfortunately the button to close the Kartographer map is an html anchor element (<a>) to an empty hash (#), and expects this function to be called when that navigation to an empty hash happens.
So, presumably, if the Media Viewer sets its route handler first (when you open an image) then that's what gets called when the Kartographer close button is clicked - and it doesn't close - but if you open the Kartographer map first, it sets it's own handler that closes it properly. – 2804:F1...ED:16CD (talk) 04:10, 2 October 2024 (UTC)[reply]
Hmmmmm, intriguing. However I have sometimes been to a page and not clicked an image at all before I've clicked a map. Could someone create a Phabricator ticket? I haven't used it before. </MarkiPoli> <talk /><cont /> 11:09, 2 October 2024 (UTC)[reply]
phab:T376391 filed. Nardog (talk) 14:34, 3 October 2024 (UTC)[reply]

This page needs refereeing, as it has been frequently edited recently in the wake of Helene, with most of the edits being less than constructive or even outright vandalism. I've made several unsuccessful attempts to ask for increased protection. I may have been trying to use an outdated request portal, but for whatever reason the info I've supplied on the form won't "take". -- HelpMyUnbelief (talk) 20:18, 30 September 2024 (UTC)[reply]

What's the portal/form? Nardog (talk) 20:22, 30 September 2024 (UTC)[reply]
I had followed a link from a Google search result, but unfortunately I don't remember for sure exactly how I phrased my query. The best I can recall, it was "request page protection site:en.wikipedia.org"; this directed me just now to Wikipedia:Requests for page protection/Increase/Form, which worked fine. I'm willing to mark the problem down as "self-corrected". :-) — HelpMyUnbelief (talk) 04:55, 2 October 2024 (UTC)[reply]

We need to rethink the extended confirmed user right.

[edit]

Either have a user right that is given only to trusted people without any additional rights attached to it (and with a matching level of protection) or make extended confirmed be given manually. There are too many people gaming the system to be hateful pricks on editors' user pages or to push a POV on CTOPs. LilianaUwU (talk / contributions) 21:59, 30 September 2024 (UTC)[reply]

That's more of a policy/proposal type question, not a technical one. Izno (talk) 22:01, 30 September 2024 (UTC)[reply]
@LilianaUwU You don't need to have extended confirm to edit someone elses user page. You can do that logged out. Trust me. I know. My user page was vandalized repeatedly before it was semi'd indefinitely. I dream of horses (Hoofprints) (Neigh at me) 22:01, 3 October 2024 (UTC)[reply]
I'm talking about my own user page, which is ECP'd and yet gets gamers all the time. LilianaUwU (talk / contributions) 23:08, 3 October 2024 (UTC)[reply]
There can't be that many of them, according to Wikipedia:User access levels there are only 72,041 extended confirmed users total. Compare that to the 2.38 million autoconfirmed users and it already looks like a pretty severe standard. In terms of the few hateful jerks who game the system... Whatever the system is they're going to game/abuse it, but that doesn't mean why shouldn't try to make their lives harder. On the technical side we could go to one year and 1,000 edits without too much disruption, thats probably enough to keep the jerks at bay. Horse Eye's Back (talk) 22:11, 3 October 2024 (UTC)[reply]

Tech News: 2024-40

[edit]

MediaWiki message delivery 22:16, 30 September 2024 (UTC)[reply]

Something wrong with my profile

[edit]

Since yesterday I seem to have lost the option to delete. As far as I can see, nothing has changed in terms of my rights or preferences, but I no longer see "Delete" as an option on the drop-down menu. This is only affecting me on English Wikipedia. On cy I still have the same rights as yesterday and can see the same options - but I'm using the same skin on both so I don't understand why this has happened. Any thoughts? Deb (talk) 15:21, 1 October 2024 (UTC)[reply]

You are probably only missing the link. If you get a delete form at https://en.wikipedia.org/wiki/User:Deb/sandbox?action=delete then you can still delete. There are different drop-down menus depending on preferences. What is your skin, what is your drop-down menu called, and do you have a delete option on "Tools" at https://en.wikipedia.org/wiki/User:Deb/sandbox?safemode=1&useskin=vector-2022? PrimeHunter (talk) 16:58, 1 October 2024 (UTC)[reply]
Thanks, you're right. That seems even weirder. I can't see any difference in my preferences between en and cy. Using the default 2022 skin. Deb (talk) 17:05, 1 October 2024 (UTC)[reply]
I asked three questions. PrimeHunter (talk) 18:45, 1 October 2024 (UTC)[reply]
Thanks. Whatever you did seems to have worked. Deb (talk) 19:14, 1 October 2024 (UTC)[reply]

Issue I'm having with Calendar template.

[edit]

Hello, so I recently made {{Calendar}} dark mode compatible. However, when calling calendar directly, I get dark text which doesn't work with dark mode. But when calling "Calendar/table", it does work. I can't figure out why. Anyone got any ideas why?

With calendar
2024
January
Su Mo Tu We Th Fr Sa
01 02 03 04 05 06
07 08 09 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31  
 
February
Su Mo Tu We Th Fr Sa
01 02 03
04 05 06 07 08 09 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29
 
March
Su Mo Tu We Th Fr Sa
01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31  
April
Su Mo Tu We Th Fr Sa
01 02 03 04 05 06
07 08 09 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30  
 
May
Su Mo Tu We Th Fr Sa
01 02 03 04
05 06 07 08 09 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
 
June
Su Mo Tu We Th Fr Sa
01
02 03 04 05 06 07 08
09 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30  
July
Su Mo Tu We Th Fr Sa
01 02 03 04 05 06
07 08 09 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31  
 
August
Su Mo Tu We Th Fr Sa
01 02 03
04 05 06 07 08 09 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
 
September
Su Mo Tu We Th Fr Sa
01 02 03 04 05 06 07
08 09 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30  
 
October
Su Mo Tu We Th Fr Sa
01 02 03 04 05
06 07 08 09 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  
 
November
Su Mo Tu We Th Fr Sa
01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
 
December
Su Mo Tu We Th Fr Sa
01 02 03 04 05 06 07
08 09 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31  
 
With calendar/table
January
Su Mo Tu We Th Fr Sa
01
02 03 04 05 06 07 08
09 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31  
February
Su Mo Tu We Th Fr Sa
01 02 03 04 05
06 07 08 09 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29  
 
March
Su Mo Tu We Th Fr Sa
01 02 03 04
05 06 07 08 09 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
 
April
Su Mo Tu We Th Fr Sa
01
02 03 04 05 06 07 08
09 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30  
May
Su Mo Tu We Th Fr Sa
01 02 03 04 05 06
07 08 09 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31  
 
June
Su Mo Tu We Th Fr Sa
01 02 03
04 05 06 07 08 09 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
 
July
Su Mo Tu We Th Fr Sa
01
02 03 04 05 06 07 08
09 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31  
August
Su Mo Tu We Th Fr Sa
01 02 03 04 05
06 07 08 09 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  
 
September
Su Mo Tu We Th Fr Sa
01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
 
October
Su Mo Tu We Th Fr Sa
01 02 03 04 05 06 07
08 09 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31  
 
November
Su Mo Tu We Th Fr Sa
01 02 03 04
05 06 07 08 09 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30  
 
December
Su Mo Tu We Th Fr Sa
01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31  

Thanks, —Matrix(!) {user - talk? - uselesscontributions} 16:56, 1 October 2024 (UTC)[reply]

Fixed in Special:Diff/1248831925. HTML elements with "background" in the CSS code get overridden text color. So either the "background" properties need to be removed (like in {{Calendar}}), or color: var(--color-base, #202122) added (example). —⁠andrybak (talk) 18:20, 1 October 2024 (UTC)[reply]
Thank you! —Matrix(!) {user - talk? - uselesscontributions} 19:09, 1 October 2024 (UTC)[reply]

Embedded anchors in tables

[edit]

I've noticed that it's possible to use links to the individual entries at WP:RSP, e.g. WP:RSP#Alexa Internet, even though there's no normal embedded anchor. I'm guessing this has to do with the id="Alexa Internet" line. I'd like to add similar functionality to {{NRHP row}}, so that it'll be possible to link directly to an entry without its own article. Would the way to do this be to add an id="{{{name|}}}" line to the template? Is there anything else I should be aware of with this? Sdkbtalk 04:30, 2 October 2024 (UTC)[reply]

@Sdkb: See Template:Anchor#Use in tables (paragraph beginning If it is necessary for an anchor to be in any of these positions) for examples of the id= attribute in tables. Please note that the value of an id= attribute must be unique within the document. This means that id="{{{name|}}}" is potentially invalid, since if you use {{NRHP row}} more than once (a highly likely situation), and two or more of them have no |name= parameter, you will end up with two different instances of id="". Try something like {{#if:{{{name|}}}|id="{{{name|}}}"}} to prevent empty ids. --Redrose64 🌹 (talk) 09:33, 2 October 2024 (UTC)[reply]
https://html.spec.whatwg.org/multipage/dom.html#global-attributes says: "When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character. The value must not contain any ASCII whitespace." ASCII whitespace includes a normal space but I would ignore this rule. It means some features cannot reference the id but if it's only intended for links then it shouldn't be a problem. I would be surprised if any browser refuses to jump to an id which breaks the rule. The issue can be avoided by placing id inside the content of a cell which doesn't count as a HTML element. But links work better if id is in the row declaration like WP:RSP and many other tables where we break the rule. This ensures the browser jumps to the top of the row. If id is at the start of cell content with vertical centering then the browser may jump to the start of the displayed content in that cell, and the top of the row may not be visible. PrimeHunter (talk) 11:22, 2 October 2024 (UTC)[reply]
Not sure what you mean by the content of a cell doesn't count as an HTML element. Table cells are either <td> or <th> HTML elements. isaacl (talk) 16:49, 2 October 2024 (UTC)[reply]
I was thinking of <td>something with id="foo bar"</td>, but you need something to apply the id to and if you do <td><span id="foo bar"></span></td> then it's just another HTML element so my comment was probably wrong or irrelevant. PrimeHunter (talk) 19:55, 2 October 2024 (UTC)[reply]
@PrimeHunter: Whilst the HTML spec does say that, the MediaWiki software replaces any spaces in the id= value with underscores before the page is served (see also Template talk:Anchor#Underscores with substitution). It does something similar with the URL fragment, which is why a link to https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Embedded%20anchors%20in%20tables works. --Redrose64 🌹 (talk) 18:54, 2 October 2024 (UTC)[reply]
Thanks for the info. PrimeHunter (talk) 19:55, 2 October 2024 (UTC)[reply]
Note also that it is possible for multiple NRHP rows (in the same page) to have the same name, which would also result in duplicate ids. I'm virtually certain such a situation exists somewhere in the several thousand NRHP list pages. (It is less likely that the name field in a row is in fact blank.) A more likely candidate to use for an anchor id would be the refnum, which should be unique across all of the rows in a given page. Magic♪piano 18:31, 2 October 2024 (UTC)[reply]

Substitution issue

[edit]

I developed the {{Happy Adminship/year}} subtemplate to read pages like Wikipedia:Birthday Committee/Calendar/October/2 and return the year someone became an admin if it's listed. (This, in turn, can be used at {{Happy Adminship}} to automatically provide the anniversary number.) It works (preview {{Happy Adminship/year}} at User talk:JHunterJ), except when substituted, which is unfortunately the way I need it to work since Happy Adminship is meant to be substed. Would anyone be able to identify what issue is causing the substitution to fail? Sdkbtalk 09:04, 2 October 2024 (UTC)[reply]

subst doesn't make transclusions in the target page unless they have subst there. Wikipedia:Birthday Committee/Calendar/October/2 contains {{u|JHunterJ}} (2007). When used on User talk:JHunterJ you tried to match on JHunterJ]] (2007) which would be in the result after transclusion of {{u}}. I have instead matched directly on JHunterJ}} (2007).[6] If you want it to work for both transclusion and substitution then you can match on both ]] and }}. Comments are included by subst so I noincluded the comment. PrimeHunter (talk) 11:54, 2 October 2024 (UTC)[reply]
Thanks! I spent way too long trying to figure that out, and would've spent a lot longer without your help! Sdkbtalk 15:38, 2 October 2024 (UTC)[reply]

Automatic citation generation isn't working?

[edit]

Is it just me or has automatic citation generation often not been working for the past couple of days? E.g. I just tried adding a citation to https://x.com/fbirol/status/1727552771715395655 and got the dreaded " We couldn't make a citation for you. Try another source or create one manually using the "Manual" tab above" message. But when I add the same source to Zotero and then export a Wikipedia citation from Zotero, Zotero creates a well-formatted wikitext citation. The same thing is happening with citations to the New York Times. What makes this more odd is that I can't duplicate the problem if I try to cite a source that is already used on the page. Clayoquot (talk | contribs) 17:55, 2 October 2024 (UTC)[reply]

This is an ongoing issue. Near as we can tell there's a number of popular sources that wind up blocking our citation-generation service. Probably automatically, based on rate limiting when enough people have requested citations within a short enough time window.
There's an umbrella ticket for this: T362379: Several major news websites (NYT, NPR, Reuters...) block citoid. DLynch (WMF) (talk) 19:21, 2 October 2024 (UTC)[reply]
Good to know. Thanks! Clayoquot (talk | contribs) 19:56, 2 October 2024 (UTC)[reply]

Pageviews of wiki.phtml

[edit]

Yesterday's topviews list (1 October 2024) has an unusual item I haven't seen before: with 96,959 views, the 24th-most-viewed page is supposedly wiki.phtml, a page that's apparently never existed. It was the 124th-most-viewed the day before. Wondering what's driving traffic (the Internet Archive has saved the URL a few times over the years) and how views are tracked for a non-existent page. Hameltion (talk | contribs) 22:04, 2 October 2024 (UTC)[reply]

Not an answer as to why it's listed, but instead of for example w/index.php?title=Pete_Rose, you can do w/wiki.phtml?title=Pete_Rose. – 2804:F1...93:F040 (talk) 22:27, 2 October 2024 (UTC)[reply]
It may be irrelevant but as an admin I can see two deleted revisions from July 2004. The first only said [[Wikipedia:Dewey Decimal System/103|103]]. The second a minute later added {{delete}}. The oldest entries at Special:Log/delete are from December 2004. PrimeHunter (talk) 23:18, 2 October 2024 (UTC)[reply]
Interesting about now-unlogged deletions ... 2 Oct recorded another 90,551 views yesterday, but massviews based on wikilinks (using the redlink here at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)) sees only 3 views all-time. Can't seem to reproduce any views at all for other redlinks this way, though. Hameltion (talk | contribs) 17:20, 3 October 2024 (UTC)[reply]
Just sounds like a bot that needs to be told to find something else to hit. Izno (talk) 23:23, 2 October 2024 (UTC)[reply]
Yeah it was the old URL before index.php; see a random example of its use. @PrimeHunter:, it's listed in the first july 2004 deletion log. Graham87 (talk) 01:01, 3 October 2024 (UTC)[reply]
Thanks. I have linked Wikipedia:Historical archive/Logs/Deletion log in MediaWiki:Dellogpagetext which is displayed at Special:Log/delete.[7] PrimeHunter (talk) 01:48, 3 October 2024 (UTC)[reply]
@PrimeHunter: Thanks but sorry, as the person who restored the old deletion logs back in 2016 (see below), I'm not comfortable with that page being linked so prominently (it actually never has been linked in that system message until now). My two main reasons are that (a) the number of people who'll need to make use of it will be vastly lower than the number of people who will misunderstand it and/or try to mess up related links (I have personal experience with this sort of thing from way back in 2007 with a similar situation relating to the old block log ) and (b) the deletion reasons often quoted the original text of the page, meaning that they contain a lot of personal information and general nastiness. The latter point is the reason many of the deletion logs were deleted between 2006 and 2016; it's quite a story how I came to restore them. I'll therefore partially revert your edit to the MediaWiki namespace page, citing this comment. Graham87 (talk) 06:17, 3 October 2024 (UTC)[reply]
As a compromise, I'm going to add a note about the old deletion logs to an interface message that appears when undeleting pages, MediaWiki:Undeletehistory, as you'd only see a list of deleted edits without a deletion log if you're an admin ... and then only for pages deleted on or after 8 June 2004. Graham87 (talk) 06:53, 3 October 2024 (UTC)[reply]
@Graham87: OK. The search box on Wikipedia:Historical archive/Logs/Deletion log fails because the prefix is wrong after page moves. Do you want it fixed or should the search box be removed to make the logs less accessible? PrimeHunter (talk) 11:53, 3 October 2024 (UTC)[reply]
@PrimeHunter: Thanks for pointing that out ... I've fixed it. Graham87 (talk) 12:20, 3 October 2024 (UTC)[reply]

Auto-creation of a local account failed

[edit]

When trying to login to another Wikipedia for which I don't have a local account like https://mos.wikipedia.org I get the error:

Auto-creation of a local account failed: Cannot create account: The username is already in use. Please pick another name.

Any workaround? Killarnee (talk) 01:58, 3 October 2024 (UTC)[reply]

@Killarnee: Have you both tried when you were already logged in at another wiki and when you logged out first? PrimeHunter (talk) 02:18, 3 October 2024 (UTC)[reply]
@Dreamy Jazz maybe relevant to your existence given what you're working on. Izno (talk) 03:30, 3 October 2024 (UTC)[reply]
It works for me. Special:CentralAuth/Killarnee says: "Global group: Two-factor authentication testers". Maybe that causes problems. The error message sounds like something that shouldn't happen but it's apparently a combination where MediaWiki:Authmanager-authn-autocreate-failed is called with MediaWiki:Centralauth-account-unattached-exists. The Killarnee account does not exist at https://mos.wikipedia.org but the bottom of Special:CentralAuth/Killarnee shows an unattached account at wikitech:User:Killarnee. This may be relevant. If it's your account then can you merge it at Special:MergeAccount or wikitech:Special:MergeAccount? PrimeHunter (talk) 04:13, 3 October 2024 (UTC)[reply]
It was the Wikitech account and after the merge it works. Thanks a lot. Killarnee (talk) 12:05, 3 October 2024 (UTC)[reply]

Can someone not a maintainer read a file on toolforge?

[edit]

ChristieBot (which maintains GAN) is crashing, and I'm not going to be at a computer where I can get to toolforge till Sunday. This is particularly frustrating because there is a GAN backlog drive going on at the moment, and until this is fixed no updates to the GAN page can take place. The problem is probably caused by a malformed template on a GAN page (at least that's usually been the cause of unexplained errors in the past), but I've no way to see the error file on toolforge. I don't know if toolforge files are visible to people who are not maintainers, but if anyone here has access, please take a look at the log file christiebot-gan.err in tool ganfilter and email me or post here the last fifty or so lines. I'm hoping there will be an error message indicating what page it was working on when the crash occurred. It's likely that the crash is due to an uncaught exception as I'm not a very experienced Python coder, but with luck the preceding log messages will help identify the page so it can be cleaned up, which should let the bot run. Thanks for any help. Mike Christie (talk - contribs - library) 03:16, 3 October 2024 (UTC)[reply]

Sure Mike. Hawkeye7 (discuss) 03:29, 3 October 2024 (UTC)[reply]
christiebot-gan.err
CRITICAL: Exiting due to uncaught exception OtherPageSaveError: Edit to page [[User talk:ChristieBot/Bug messages]] failed:
Editing restricted by {{bots}}, {{nobots}} or site's equivalent of {{in use}} template
Sleeping for 9.1 seconds, 2024-10-03 02:40:05
Page [[User talk:ChristieBot/GAN errors]] saved
Page [[Talk:Luochahai City]] saved
Traceback (most recent call last):
  File "/data/project/ganfilter/www/python/src/GANbot.py", line 307, in <module>
    nom.add_a_review(gan_conn)
  File "/data/project/ganfilter/www/python/src/GA.py", line 882, in add_a_review
    GAN.notify_error("GANbot: add_a_review","counting reviews", "found prior review for " + str(self.title) + '/' + str(self.page_num) + " by " + str(row['reviewer']), False)
  File "/data/project/ganfilter/www/python/src/GA.py", line 2284, in notify_error
    page.save("Reporting an error in " + location)
  File "/data/project/ganfilter/www/python/venv/lib/python3.11/site-packages/pywikibot/page/_basepage.py", line 1273, in save
    raise OtherPageSaveError(
pywikibot.exceptions.OtherPageSaveError: Edit to page [[User talk:ChristieBot/Bug messages]] failed:
Editing restricted by {{bots}}, {{nobots}} or site's equivalent of {{in use}} template
CRITICAL: Exiting due to uncaught exception OtherPageSaveError: Edit to page [[User talk:ChristieBot/Bug messages]] failed:
Editing restricted by {{bots}}, {{nobots}} or site's equivalent of {{in use}} template
Sleeping for 9.1 seconds, 2024-10-03 03:00:09
Page [[User talk:ChristieBot/GAN errors]] saved
Page [[Talk:Holzwarth gas turbine]] saved
Traceback (most recent call last):
  File "/data/project/ganfilter/www/python/src/GANbot.py", line 307, in <module>
    nom.add_a_review(gan_conn)
  File "/data/project/ganfilter/www/python/src/GA.py", line 882, in add_a_review
    GAN.notify_error("GANbot: add_a_review","counting reviews", "found prior review for " + str(self.title) + '/' + str(self.page_num) + " by " + str(row['reviewer']), False)
  File "/data/project/ganfilter/www/python/src/GA.py", line 2284, in notify_error
    page.save("Reporting an error in " + location)
  File "/data/project/ganfilter/www/python/venv/lib/python3.11/site-packages/pywikibot/page/_basepage.py", line 1273, in save
    raise OtherPageSaveError(
pywikibot.exceptions.OtherPageSaveError: Edit to page [[User talk:ChristieBot/Bug messages]] failed:
Editing restricted by {{bots}}, {{nobots}} or site's equivalent of {{in use}} template
CRITICAL: Exiting due to uncaught exception OtherPageSaveError: Edit to page [[User talk:ChristieBot/Bug messages]] failed:
Editing restricted by {{bots}}, {{nobots}} or site's equivalent of {{in use}} template
Sleeping for 9.0 seconds, 2024-10-03 03:20:17
Page [[User talk:ChristieBot/GAN errors]] saved
Page [[Talk:Holzwarth gas turbine]] saved
Traceback (most recent call last):
  File "/data/project/ganfilter/www/python/src/GANbot.py", line 307, in <module>
    nom.add_a_review(gan_conn)
  File "/data/project/ganfilter/www/python/src/GA.py", line 882, in add_a_review
    GAN.notify_error("GANbot: add_a_review","counting reviews", "found prior review for " + str(self.title) + '/' + str(self.page_num) + " by " + str(row['reviewer']), False)
  File "/data/project/ganfilter/www/python/src/GA.py", line 2284, in notify_error
    page.save("Reporting an error in " + location)
  File "/data/project/ganfilter/www/python/venv/lib/python3.11/site-packages/pywikibot/page/_basepage.py", line 1273, in save
    raise OtherPageSaveError(
pywikibot.exceptions.OtherPageSaveError: Edit to page [[User talk:ChristieBot/Bug messages]] failed:
Editing restricted by {{bots}}, {{nobots}} or site's equivalent of {{in use}} template
CRITICAL: Exiting due to uncaught exception OtherPageSaveError: Edit to page [[User talk:ChristieBot/Bug messages]] failed:
Editing restricted by {{bots}}, {{nobots}} or site's equivalent of {{in use}} template

Hawkeye7 (discuss) 03:29, 3 October 2024 (UTC)[reply]

I can see the problem. I will leave it to you though. Hawkeye7 (discuss) 03:33, 3 October 2024 (UTC)[reply]
Thanks, Hawkeye7; I've fixed the issue, and I really appreciate you posting this so quickly. Mike Christie (talk - contribs - library) 07:23, 3 October 2024 (UTC)[reply]

Watchlist icon issue on Mobile

[edit]

Hey, I am facing an issue with mobile editing. I am unable to see the ‘Star’ icon after adding an article to my watchlist. The spot where it used to be is now just a blank white space. When I click there, it works and removes the article from the watchlist, and the star appears. However, when I add the article to the watchlist again, the star disappears. This issue is not occurring on desktops. Can anyone else editing through mobile confirm this? GrabUp - Talk 12:27, 3 October 2024 (UTC)[reply]

I was just going to post a question about this. I would be interested in an answer about the 'invisible' watchlist star. Thanks for posting this @GrabUp:. Knitsey (talk) 17:31, 3 October 2024 (UTC)[reply]
@Knitsey: Also, my notification icon is getting invisible whenever someone like you tags or mentions me. What’s going on, lol? GrabUp - Talk 17:34, 3 October 2024 (UTC)[reply]
I've just noticed that. I was tagged in a post and my icon was red but disappeared after I looked at it, another blank space. Knitsey (talk) 17:37, 3 October 2024 (UTC)[reply]
Correction, when I have a notification, it shows up as white background with slighty off white mumber of notifications. (The red notification has gone). Knitsey (talk) 17:40, 3 October 2024 (UTC)[reply]
Yes, same. GrabUp - Talk 17:44, 3 October 2024 (UTC)[reply]
@Jon (WMF) Izno (talk) 17:36, 3 October 2024 (UTC)[reply]
It looks like this is tracked at phab:T376359. Thanks. Quiddity (WMF) (talk) 18:09, 3 October 2024 (UTC)[reply]
New task created (phab:T376414) for the Notification background color bug. Quiddity (WMF) (talk) 18:29, 3 October 2024 (UTC)[reply]
[edit]

The issues with links that shouldn't be blue being blue are thankfully fixed, but now there is a new problem. All categories, links in talk page banners, and links in maintenance banners are now underlined at all times. This is not the case on the desktop version. Is this intended, or is it another visual bug? Thanks, QuicoleJR (talk) 14:10, 3 October 2024 (UTC)[reply]

I've just seen this, appears to be a new development today. AusLondonder (talk) 17:28, 3 October 2024 (UTC)[reply]
It looks like one aspect of this is covered by phab:T376146. I'll followup with the devs to see if that task covers these other aspects, or if they need separate tasks. Thanks for reporting. Quiddity (WMF) (talk) 17:37, 3 October 2024 (UTC)[reply]

Interlang bug

[edit]

So I'm not going to need a photo for this bug since it's on my user page. When going on my user page, do you see an interlanguage link in French? If so, then click on it and it'll go to a random French bombing article. The issue is that my user page isn't on the wikidata, which is normally how you link languages. I was translating that article, and for some reason it thinks my user page is the article I translated. SirMemeGod14:34, 3 October 2024 (UTC)[reply]

@Sir MemeGod You had one of the old-style of interlanguage links on your user page. To include a normal link to a page on another language, you have to precede it with a colon i.e. [[:fr:Attentat du 25 juillet 1995 à la gare de Saint-Michel du RER B]]. I fixed it for you. the wub "?!" 14:53, 3 October 2024 (UTC)[reply]
@Sir MemeGod: It's not a bug, it's described at WP:LOCALLINK, and there are times when it's desirable. For example, see the languages list for User:Redrose64 - this is all the Wikis that I have edited over the last fifteen years. If I had added these to Wikidata, the same long list would be shown on my home pages at dozens of other Wikis - but I don't want that, I only want one to be shown - the link back to my homepage here. See for example cy:Defnyddiwr:Redrose64 or fr:Utilisateur:Redrose64. In this way, I prevent people at French Wikipedia looking in vain on German Wikipedia, and trying Wiki after Wiki until they reach the right one. --Redrose64 🌹 (talk) 18:26, 3 October 2024 (UTC)[reply]
Oh, okay. It seemed like a bug to me, but I guess I was wrong. SirMemeGod18:28, 3 October 2024 (UTC)[reply]

Database error, write duration exceeded

[edit]

Just got the following error message dropping three See-alsos from a Draft, in this edit:

Database error
To avoid creating high replication lag, this transaction was aborted because the write duration (5.3958411216736) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.

[bf82d77e-9cdf-4b96-a5b2-5ac9cab8969a] 2024-10-03 15:00:40: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

The edit seems to have gone through fine, despite the message. Could this happen if I inadvertently hit Publish twice or something? I don't have any recollection of doing so, and I really don't know what happened. Everything is fine on my end, I don't need any action, just reporting this in case it's a first sign of something going on that needs to be watched. Mathglot (talk) 15:11, 3 October 2024 (UTC)[reply]

Why are the buttons glitched out/distorted

[edit]

The delete template (while editing an article), wikitext (while viewing a revision) and edit template (while editing an article) buttons are glitched out and/or distorted. How do I fix this?? Susbush (talk) 15:12, 3 October 2024 (UTC)[reply]

I think this is the same problem as T376226, which is being fixed. Matma Rex talk 18:24, 3 October 2024 (UTC)[reply]
Yes it is Susbush (talk) 18:56, 3 October 2024 (UTC)[reply]

Help Escalating security issue with Webauthn

[edit]

With the help of WMF staff we identified a critical issue with webauthn that is likely locking users out of their accounts. The issue prevents webauthn activated on a device from being used on another device, or between browser sessions. This means users can be activating webauthn , intending to secure their account, and end up losing access to wikipedia. Because relatively few users activate this feature in the short term, the issue may not be getting the attention it deserves. It will also discourage future users from activating webauthn, which is a critical security feature to protect the community.

Please help me find the appropriate contact with WMF technical staff to help get the fix merged. It's a one-line fix from upstream repository so it should be low risk. Tonymetz 💬 16:50, 3 October 2024 (UTC)[reply]

I guess that would be us, the Platform Team. I'll raise it with the team and we'll have a look. Matma Rex talk 19:30, 3 October 2024 (UTC)[reply]
Thanks for the note, webauthn has multiple known issues and is certainly in the "experimental" role. As far as our contributors and readers here at the English Wikipedia go: webauthn shouldn't be used by anyone for anything important. Technical reports in phabricator are of course welcome. — xaosflux Talk 00:09, 5 October 2024 (UTC)[reply]

"Add A Fact" LLM browser extension

[edit]

After reading [8] and the post and ensuing discussion here, I don't think this browser extension is ready for article talk pace on en.wiki. I'm not exactly sure where to voice a concern about this, so please move this feedback if appropriate. @Chemipanda, Ita140188, and Avatar317: VQuakr (talk) 20:04, 3 October 2024 (UTC)[reply]

@VQuakr Feedback should probably go to meta:Talk:Future_Audiences/Experiment:Add_a_Fact. --Ahecht (TALK
PAGE
)
21:05, 3 October 2024 (UTC)[reply]
That would be fine for feedback to them; I guess here I'm more looking to see if there's agreement this shouldn't be used on en.wiki yet. VQuakr (talk) 21:20, 3 October 2024 (UTC)[reply]
@VQuakr For reference, here is a list of all the edits made using this tool: https://hashtags.wmcloud.org/?query=addafact&project=en.wikipedia.org&startdate=&enddate=&search_type=or&user= 86.23.109.101 (talk) 21:59, 3 October 2024 (UTC)[reply]
That is a helpful link, thanks!! I glanced at ~10 random ones, and they all looked fine; They were a sentence directly copied from the source with the text listed in the quote parameter for the cite. Maybe Chemipanda didn't use it properly (highlighted the title) or is running an outdated browser version? Editors should at least look at their generated posts to see whether they are normal/valid/coherent and revert them if not; this tool is still experimental.
If this were to work as promised, I see this as more helpful than people simply posting new sources in the Talk pages. (which is always helpful). ---Avatar317(talk) 22:39, 3 October 2024 (UTC)[reply]
@Avatar317 Yes, Looking through the edits my impression is that most of them are fine.
According to the page on meta the person using the tool has to select which part of the source to use, so the "adding the title of a paper rather than it's content" is user error, rather than an issue with the tool. There is still the issue of using the wikipedia page in the citation template that needs to be investigated though. 86.23.109.101 (talk) 11:54, 4 October 2024 (UTC)[reply]
[edit]

Not sure if here or the Help desk is the right place... Anyway, I've two questions, please:

  1. Is there a way (e.g., a tool) to extract diffs without going through the page history?
  2. When I click on the timestamp of a signature, I get a comment-specific link (e.g., [9]). I couldn't find any help pages about this kind of link. Is there a reason why we provide diffs instead of these comment-specific links, which seem much easier to obtain?

Thanks, Gitz (talk) (contribs) 09:56, 4 October 2024 (UTC)[reply]

For your question 2, they are described at mw:Help:DiscussionTools § Talk pages permalinking. jlwoodwa (talk) 16:31, 4 October 2024 (UTC)[reply]
The comment links are a fairly new feature, only enabled on English Wikipedia in June (T365974). I suspect many editors haven't warmed up to them yet. Diffs may also be used in some cases if you want to avoid ambiguity as to who wrote what, since anyone can technically edit anything on any page. Comment links are much more convenient for reading or commenting in the linked discussion though. Matma Rex talk 17:19, 4 October 2024 (UTC)[reply]
By extract diffs you mean? Izno (talk) 18:28, 4 October 2024 (UTC)[reply]
Thank you all for your helpful responses - I wasn't aware of that Help page. By "extract diffs" I meant accessing or generating the diffs directly from the talk page, without manually navigating through the page history. When I hover over the timestamp, I see a series of options ("actions", "popups") but none for getting the diff, so I was wondering if there's a tool or shortcut to generate one. Gitz (talk) (contribs) 20:02, 4 October 2024 (UTC)[reply]
No, I don't think there's a tool like that. Izno (talk) 20:46, 4 October 2024 (UTC)[reply]
Diffs between what, from what talk page? Please provide an example. Nardog (talk) 22:56, 4 October 2024 (UTC)[reply]
I assume Gitz6666 means the diff in which that comment was written. jlwoodwa (talk) 23:00, 4 October 2024 (UTC)[reply]
Yes, that's what I meant - a direct way for obtaining this [10] from this [11] without going through the page history. Gitz (talk) (contribs) 23:16, 4 October 2024 (UTC)[reply]
If you use a browser that supports Chrome or Firefox extensions, you can try the mw:Who Wrote That? browser extension. isaacl (talk) 23:28, 4 October 2024 (UTC)[reply]
"WWT only works on article pages (not talk, user, or other pages)." Nardog (talk) 23:30, 4 October 2024 (UTC)[reply]
Sorry; for some reason, the mention of signatures didn't make me think about non-article pages. isaacl (talk) 23:34, 4 October 2024 (UTC)[reply]

I dislike the visual changes to Mobile Wikipedia

[edit]

I havent used the community pool before so Im sorry if this isnt in the right village. mobile wikipedia starting today as for some reason started auto directing me to en.m.wikipedia.org instead of the regular en.wikipedia.org. even if i directly remove the ".m" or "m.", it will just autodirect to it again. I really hate it, and find it unbearable to use and love the regular english language wikipedia much more. I dont know what is causing this problem. I havent seen anyone discussing this on either the wikipedia subreddit (where usually any updates are discussed) or on Wikipedia:News. I greatly appreciate any help with this, thank you! 92.236.211.53 (talk) 13:55, 4 October 2024 (UTC)[reply]

Use the "Desktop" link at the bottom of mobile pages to request the desktop version. PrimeHunter (talk) 14:00, 4 October 2024 (UTC)[reply]
Thank you for your quick response! I already tried this and it unfortunately results in it providing the literal desktop version of the website, resulting in large amounts of negative space and awkward text placement next to images due to website trying to work for the horizontal mobile. the site worked perfectly for mobile prior. is this happening on your phone too? 92.236.211.53 (talk) 14:07, 4 October 2024 (UTC)[reply]
im typing from desktop as i also learned today that my phone's ip (this same ip) was caught up in a rangeblock to block a specific user(but is now resolved?). i thought just now that this might be whats causing this but i just made account on mobile and it still autodirects to en.m.wikipedia. i have no idea what to do 92.236.211.53 (talk) 14:28, 4 October 2024 (UTC)[reply]
Device name:Pixel 6a
Model:Pixel 6a
Android version:12
I wish this information perhaps helps in finding out how to reverse this. I sent this from my mobile. 92.236.211.53 (talk) 16:48, 4 October 2024 (UTC)[reply]
The behavior you're experiencing is how it has always worked. The "workaround" Primehunter provided is working how it has always worked. There isn't a way to "fix it". The closest thing you can do is have an account, change the account's skin preference, and then use the "use desktop" link when you are logged in and end up on the mobile website. Perhaps this is sufficient for you. Izno (talk) 18:31, 4 October 2024 (UTC)[reply]
I went back through screenshots I took and saw that you and Primehunter were right, it has always been "en.m.wikipedia". I think there's been an update to mobile Wikipedia's base, light colour scheme that caused the add-on I was using, darkreader to render it differently.
I do notice that the text on tables is larger, and colours are in my opinion not working well together either in the official dark mode or using my add-on on light mode.
Current, disliked Wikipedia (lightmode+darkreader) from today: https://imgur.com/a/wnNflgF
Correct Wikipedia, just darkmode with no add-ons, also today:https://imgur.com/a/4xdBsow
Previous mobile Wikipedia colour scheme (lightmode+darkreader), from 28th of April: https://imgur.com/a/up24a8G
Is there anyway to go back to how it was previously because I really do prefer how it was literally just yesterday? I'm sincerely sorry for the misunderstandings 92.236.211.53 (talk) 19:33, 4 October 2024 (UTC)[reply]
What specifically do you dislike about the "current" version? Izno (talk) 00:09, 5 October 2024 (UTC)[reply]

Is AutoEd safe

[edit]

I installed the script and all of its modules, is it safe or not? Electrou (formerly Susbush) (talk) 19:00, 4 October 2024 (UTC)[reply]

You're responsible equally for all the edits made with automated tools, if that's what you're asking. You still have to check to make sure your edits are correct and not disruptive. Remsense ‥  19:04, 4 October 2024 (UTC)[reply]
The original poster is probably referring to the message that begins "Code that you insert on this page could contain malicious content capable of compromising your account ..." at MediaWiki:Userjsdangerous. To answer the original question, yes, it is safe. Graham87 (talk) 02:05, 5 October 2024 (UTC)[reply]
You can never be sure of that about user scripts (hence the warning). AutoEd and its modules are in the Wikipedia namespace and protected, which means they can be compromised if any admin's account is compromised. Nardog (talk) 02:12, 5 October 2024 (UTC)[reply]

Wikisource & HTTP 429

[edit]

There is an issue with Wikisource and error 429 which could use more technical eyes. Please see this commons discussion and this WS discussion. Thanks for any help or advice you can give. Cremastra (talk) 23:44, 4 October 2024 (UTC)[reply]

Production system errors should be reported via this phabricator form. Has a ticket been opened there yet? — xaosflux Talk 00:00, 5 October 2024 (UTC)[reply]
I don't believe so. A WMF employee said they would file a phabricator task, so we should probably wait so a duplicate doesn't get created by accident. Cremastra (talk) 01:20, 5 October 2024 (UTC)[reply]

How do title bar colors get into an infobox?

[edit]

I'm trying to track down where to flag inaccessible colors in an infobox.

For example, the page Oakland Coliseum station has a station infobox in which titles have insufficient contrast with their background. But if I look at the infobox code on that page, I only find the parameter:

style = BART

and no color coding. So apparently the BART style is stored somewhere else. And so it doesn't make sense for me to flag Oakland Coliseum station but rather wherever the BART style is stored. But I have no idea how to track that down. In fact, if I read the {{Infobox station#External_style_template}} documentation, it says that the above code should correspond to an existing {{BART style}} template. But that template doesn't seem to exist.

How do I find the problematic code? Thisisnotatest (talk) 01:34, 5 October 2024 (UTC)[reply]

Module:Adjacent stations/BART? Nardog (talk) 02:16, 5 October 2024 (UTC)[reply]
Thank you! That was worth checking. Unfortunately, that doesn't seem to be it. Of course, if it was it, the documentation for {{Infobox station#External_style_template}} would need to be updated to allow for other sources than {{BART style}}.
But it isn't. Module:Adjacent stations/BART is using a light blue of #00aeef while the light blue in the Oakland Coliseum station infobox is a light blue of #0099d8.
So still looking. Thisisnotatest (talk) 02:38, 5 October 2024 (UTC)[reply]
Oops! Just looked at the source code. That does appear to be it. The documentation for that module doesn't mention the infobox header colors. So the documentation for {{Infobox station#External_style_template}} does need to be updated. I'll post on the talk page of both items, as I'm not Lua-savvy nor infobox savvy. Anyway, major thanks! Thisisnotatest (talk) 02:43, 5 October 2024 (UTC)[reply]

Template Data report for talk page usage

[edit]

Adding Template Data to a template makes a parameter usage report available. Here's one for {{cite archive}}: [12] Is there a way to use this on templates that are meant for talk pages? For example, {{Archive}} is used on hundreds of thousands of pages (in the talk namespaces), but its report only shows a couple of uses in the Portal namespace: [13] Rjjiii (talk) 03:21, 5 October 2024 (UTC)[reply]