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.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
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]
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:
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. AwesomeAasim04: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]
I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. AwesomeAasim13: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. AwesomeAasim19: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.
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. AwesomeAasim12:52, 2 October 2024 (UTC)[reply]
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. AwesomeAasim18:21, 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!) AwesomeAasim00: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. AwesomeAasim23: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. AwesomeAasim03: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''}}.
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. AwesomeAasim14: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. AwesomeAasim01: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.
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? AwesomeAasim04:02, 2 October 2024 (UTC)[reply]
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.
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]
@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]
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]
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. AwesomeAasim06:15, 26 September 2024 (UTC)[reply]
No, it works with new tabs just as well as anything else:
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:
Gadgets must work if just included with no further configuration.: This script requires no configuration at all.
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.
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.
Duplication of gadgets should only be made if it is reasonable.: This does not apply.
Collections of scripts should be split if they have disparate functions.: This does not apply.
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.
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. AwesomeAasim18: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. AwesomeAasim19: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. AwesomeAasim13:02, 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. AwesomeAasim15:23, 2 October 2024 (UTC)[reply]
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.
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.
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 (talk • contribs) 06:49, 26 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 here03: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 here03: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 here03:21, 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.
@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 here07: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]
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]
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]
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.
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. — xaosfluxTalk15:39, 2 October 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]
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. — xaosfluxTalk00: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 (talk • contribs) 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]
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]
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]
With window.popupPreviewFirstParOnly = false; in the browser console I see }} and below it the opening paragraph. Popups apparently misreads the complicated infobox as an opening paragraph only containing }}. {{ and }} are correctly balanced in the article. PrimeHunter (talk) 11:56, 28 September 2024 (UTC)[reply]
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]
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:
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]
If I open a new topic on a talk (such as I have just done here) the software won't let me abandon it. It wants me to finish it. Like, suppose right now I decided "enh this isn't right venue" and left the page discarding my work (or wishing to). Well if I come back to this page tomorrow, it won't let me start a new thread, or edit an existing thread, or even read the page. Nope. It's like "You started a thread yesterday. I'll take you there now! FINISH IT AND POST IT chum and then we can talk about what I'll allow you do to next."
Mind you this is after I have clicked the "OK" on "Leave this page? Your work will be lost" box (that is generated by Firefox not Wikipedia). There it is again when I come back. I can erase the text, but can't entirely erase the title ("You can't have a blank title!") nor delete the thread. I suppose if I were to drop dead it would start harassing my estate to finish the post, I don't know.
This is no good. Can this be fixed? Is there a workaround? Fixing would better as that'd mean future editors would not have to climb the draperies. Thanks. Herostratus (talk) 17:34, 28 September 2024 (UTC)[reply]
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]
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]
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. LizRead!Talk!22:43, 29 September 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]
A heading beginning with a wiki comment removes MediaWiki interface "edit" buttons for that section
Demonstrated at testwiki:Sandbox/Section edit button. Notice 2 out of 6 sections have their "edit source" or "edit" buttons missing deliberately, when a section heading text is prepended with a wiki comment (see the page source). A wiki comment after a heading on the same line works, however.
I had to make an edit Special:Diff/1248413109 here at en.wiki to workaround this MediaWiki behavior, to restore said interface button. The lack of edit interface buttons in sections can be misinterpreted confusingly as a page being protected, particularly as an unregistered user.
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]
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. --Chris08: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]
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]
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.
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. LizRead!Talk!22:48, 29 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. LizRead!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]
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]
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):
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)#
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]
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]
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.
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]
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]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
Readers of 42 more wikis can now use Dark Mode. If the option is not yet available for logged-out users of your wiki, this is likely because many templates do not yet display well in Dark Mode. Please use the night-mode-checker tool if you are interested in helping to reduce the number of issues. The recommendations page provides guidance on this. Dark Mode is enabled on additional wikis once per month.
Editors using the 2010 wikitext editor as their default can access features from the 2017 wikitext editor by adding ?veaction=editsource to the URL. If you would like to enable the 2017 wikitext editor as your default, it can be set in your preferences. [3]
For logged-out readers using the Vector 2022 skin, the "donate" link has been moved from a collapsible menu next to the content area into a more prominent top menu, next to "Create an account". This restores the link to the level of prominence it had in the Vector 2010 skin. Learn more about the changes related to donor experiences. [4]
The CampaignEvents extension provides tools for organizers to more easily manage events, communicate with participants, and promote their events on the wikis. The extension has been enabled on Arabic Wikipedia, Igbo Wikipedia, Swahili Wikipedia, and Meta-Wiki. Chinese Wikipedia has decided to enable the extension, and discussions on the extension are in progress on Spanish Wikipedia and on Wikidata. To learn how to enable the extension on your wiki, you can visit the CampaignEvents page on Meta-Wiki.
Developers with an account on Wikitech-wiki should check if any action is required for their accounts. The wiki is being changed to use the single-user-login (SUL) system, and other configuration changes. This change will help reduce the overall complexity for the weekly software updates across all our wikis.
In depth
The server switch was completed successfully last week with a read-only time of only 2 minutes 46 seconds. This periodic process makes sure that engineers can switch data centers and keep all of the wikis available for readers, even if there are major technical issues. It also gives engineers a chance to do maintenance and upgrades on systems that normally run 24 hours a day, and often helps to reveal weaknesses in the infrastructure. The process involves dozens of software services and hundreds of hardware servers, and requires multiple teams working together. Work over the past few years has reduced the time from 17 minutes down to 2–3 minutes. [5]
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]
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]
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?
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? Sdkbtalk04: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]
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♪piano18:31, 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]
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.
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]
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]
@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]
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]
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
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 - Talk12: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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
. You could do all the computations behind it and create a similar chart for BRI. Uwappa (talk) 07:24, 26 September 2024 (UTC)
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)
Works for me What is your skin and browser? --Redrose64 🌹 (talk) 20:26, 28 September 2024 (UTC)
Resolved