This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
How can I convert Google Books urls to neutral format?
Object: For a citation, I want to include the url for the Google Books page. (It's in Preview mode.)
Problem: I live outside the U.S., so the url I get here is country-specific. Furthermore, the url I get includes irrelevant data, like the search term I used to find it in the first place.
Question: How do I convert the url to the country-neutral, approved short form?
Thank you, although that will give me the book, but not the page. Also, it won't work for older books since there was no ISBN then, Ttocserp11:44, 24 August 2024 (UTC)
Well, not yet. @Ttocserp: nothing on this planet is easy. There are currently 198 articles with one or more links to the German version of Google Books. And there are many languages other than German and English. Working on it. Polygnotus (talk) 12:50, 24 August 2024 (UTC)
So, this simple request led to a lot of todoes:
MediaWiki doesn't appear to have a way to filter Special:LinkSearch by namespace. many Phabricator tickets, T37758 dates back to 2012... But the functionality already exists in NewPagesPager.php so it shouldn't be too hard to make something similar.
I couldn't find a userscript that allows the user to filter Special:LinkSearch by namespace. User:Polygnotus/namespace.js does it, exceptionally poorly (it does not make API requests it just filters whatever is displayed on the page).
If there are no other scripts that do this task better then something like this should be improved and added to the list.
You might find this and variant searches useful: insource:"books.google" insource:/\/\/books\.google\.(de|fr|es|nl|pt|it)/. That search finds about 1480 articles.
The search looks for that pattern in the wikitext of pages. Linksearch looks for links in its rendered output. Consider templates like {{geoSource}}, which can produce links to google books from wikitext like {{geoSource|DE|AHL|42}}. (Or even the Template:GeoSource page itself, which has many links to google books despite that url not appearing in its wikitext at all, through its transclusion of Template:GeoSource/doc.) —Cryptic14:54, 24 August 2024 (UTC)
Since a bot can only edit URLs that literally exist in the wikitext, insource is more accurate for that purpose. Unless the bot is programmed for those special templates, which most are not since there are thousands, each with their own syntax that can change on a whim. -- GreenC13:14, 26 August 2024 (UTC)
And because it is only looking for six of the who-knows-how-many languages google books supports. And because the search is constrained to mainspace.
Probably the best task to look at is phab:T12593, which is specifically about Special:LinkSearch. It's not as simple as you seem to think, the SQL query would be too inefficient. NewPagesPager and some others have different enough table structure that efficient queries can be written. Anomie⚔16:33, 24 August 2024 (UTC)
asyncfunctionfetchGoogleBooksLinks(languageTLD){constapi=newmw.Api();letparams={action:'query',format:'json',list:'exturlusage',euquery:`books.google.${languageTLD}`,eunamespace:0,eulimit:'max'};lettitles=[];letcontinueToken;do{if(continueToken){paramseucontinue=continueToken;}console.log(`Fetching for ${languageTLD}`)constdata=awaitapi.get(params);constexturls=data.query.exturlusage;exturls.forEach((exturl)=>{titles.push(exturl.title);});continueToken=datacontinue?data.continue.eucontinue:null;}while(continueToken);returntitles;}asyncfunctionfetchAllGoogleBooksLinks(){consttlds=['de','fr','es','nl','pt','it'];letallTitles=[];for(consttldoftlds){consttitles=awaitfetchGoogleBooksLinks(tld);allTitles=allTitles.concat(titles);}console.log("* [["+allTitles.join("]]\n* [[")+"]]")}fetchAllGoogleBooksLinks();
Thank you! I know this cool little trick where I can take any piece of code and double it in size... by converting it to Java. Let me tell you, bigger is not always better. Polygnotus (talk) 12:35, 26 August 2024 (UTC)
In case it helps, I keep statistics, Enwiki has 2,122,411 Google Books links as of last month. If all you found was about 1,500 malformed links, about 0.0007 percent, is pretty good. We do have a much bigger problem with the corpus of GB links, which BTW is one of the largest corpuses<sp?> comparable to nytimes.com and web.archive.org .. the problem is that many of them have stopped working, directly (hard-404), or indirectly (soft-404 and crunchy-404 - see WP:LINKROT#Glossary). It could be 10% or more (200,000+). Nobody is really maintaining the 2 million corpus other than the URL normalization work of Citation bot. IABot typically skips them since archives usually don't work. Dead-ish GB links sit there, unresolved, often providing nothing more than an "About the book" page confirming the author and title, with a "Buy this book" button. At one time the link had content, but GB changes things around, removing content leaving little behind. All 2 million are at risk of becoming hard, soft and crunchy 404s. -- GreenC13:44, 26 August 2024 (UTC)
geohack is down
Resolved
Looking in to reports that geohack (where article coordinates go) is down. Getting 504 timeouts when following links such as [1]. — xaosfluxTalk13:37, 26 August 2024 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Feature news
Administrators can now test the temporary accounts feature on test2wiki. This was done to allow cross-wiki testing of temporary accounts, for when temporary accounts switch between projects. The feature was enabled on testwiki a few weeks ago. No further temporary account deployments are scheduled yet. Temporary Accounts is a project to create a new type of user account that replaces IP addresses of unregistered editors which are no longer made public. Please share your opinions and questions on the project talk page.
Later this week, editors at wikis that use FlaggedRevs (also known as "Pending Changes") may notice that the indicators at the top of articles have changed. This change makes the system more consistent with the rest of the MediaWiki interface. [2]
Bugs status
Editors who use the 2010 wikitext editor, and use the Character Insert buttons, will no longer experience problems with the buttons adding content into the edit-summary instead of the edit-window. You can read more about that, and 26 other community-submitted tasks that were resolved last week.
Project updates
Please review and vote on Focus Areas, which are groups of wishes that share a problem. Focus Areas were created for the newly reopened Community Wishlist, which is now open year-round for submissions. The first batch of focus areas are specific to moderator workflows, around welcoming newcomers, minimizing repetitive tasks, and prioritizing tasks. Once volunteers have reviewed and voted on focus areas, the Foundation will then review and select focus areas for prioritization.
Do you have a project and are willing to provide a three (3) month mentorship for an intern? Outreachy is a twice a year program for people to participate in a paid internship that will start in December 2024 and end in early March 2025, and they need mentors and projects to work on. Projects can be focused on coding or non-coding (design, documentation, translation, research). See the Outreachy page for more details, and a list of past projects since 2013.
Learn more
If you're curious about the product and technology improvements made by the Wikimedia Foundation last year, read this recent highlights summary on Diff.
To learn more about the technology behind the Wikimedia projects, you can now watch sessions from the technology track at Wikimania 2024 on Commons. This week, check out:
The most likely explanation is that, because of an AfD debate, the article was deleted and the pageblock then ended. And then the article was recreated, and the editor was then able to contribute to it. The current incarnation of the article was deleted by another administrator a few minutes ago, just as I was about to click the delete button. My explanation is an informed hunch and those with deeper understanding of the software may have a better explanation. Cullen328 (talk) 07:44, 28 August 2024 (UTC)
There's some edits after the page was moved. I think Cullen328 above might be on the right track. Maybe partial blocks are by page_id rather than page_title. Thank you both for the ideas. –Novem Linguae (talk) 07:48, 28 August 2024 (UTC)
Just a brief update here...
The previously blocked user is already arguing for undeletion at Requests for Undeletion, here [3].
Given that the article coudl as easily have been deleted under G5 as G4, would it not be possible for an admin to just site block the user, rather than for others to have their time wasted by his continual bad faith actions? Axad12 (talk) 08:29, 28 August 2024 (UTC)
No problem, I will open a thread at ANI and copy you in. (I will say for now however that I feel that the user's behaviour at Requests for Undeletion was quite unacceptable). Axad12 (talk) 08:57, 28 August 2024 (UTC)
@Novem Linguae Partial blocks apply to a specific incarnation of a page, not the page title (as you say, it works by page id). If you move a page to a new title the partial block should move with it.
You also cannot use a partial block to stop an editor creating a page.
Perhaps changed recently or I did not pay attention but Special:Watchlist has filter for namespace and refers to Article/Mainspace as "Content", the first I've seen it named as such anywhere. I like content but find it confusing when elsewhere e.g in Special:MovePage it's called (Article). I don't have a strong opinion on the correct name, but think we should minimize confusion. ~ 🦝 Shushugah (he/him • talk) 10:55, 28 August 2024 (UTC)
{{trout}} me 🎏 You are right! I did not read closely enough, despite bothering to report it here, because I would have expected it to select all content/talk pages then. Thank you for the informative links down MediaWiki rabbit hole! ~ 🦝 Shushugah (he/him • talk) 12:36, 28 August 2024 (UTC)
Onlyinclude allows for transclusion of hidden comments?
I was wondering, has it always been the case that <onlyinclude>...</onlyinclude> tags, if placed inside of a hidden HTML comment, will still transclude its contents when called from another page? (For example, see here and here in my sandbox.) This seems strange to me, if the code is hidden it seems like it should not be transcluded elsewhere. This doesn't seem to apply to includeonly though.
I assume it has always been like that and it seems logical to me. Comments <!-- ... --> are saved as part of the page and not stored somewhere else. If the page has onlyinclude tags inside then all other parts of the page are ignored on transclusion so the comment start and end tags are not seen. includeonly works different. A page with includeonly but no onlyinclude is processed from the beginning on transclusion so the comment tags are seen there. PrimeHunter (talk) 12:10, 28 August 2024 (UTC)
Invisible text on pending changes page histories with green on black gadget.
I use the green on black gadget available through preferences. When I go to the history of a page which has pending changes, the bytes and the user-entered edit summary for the top two entries are in black text on black. I struggle to read this. If I click-and-highlight then I can read it. I'm not sure how long ago it started. For example here. Can it be fixed? Thanks, DuncanHill (talk) 16:07, 29 August 2024 (UTC)
The other day, I had a notification I had already seen reappear a month later. Apparently this is something which is seen on occasion, but nobody knows how to reproduce it. If this happens to you, please leave comments on T373443 with whatever details you can figure out, or just email me if you don't have phab access and I can do it for you. RoySmith(talk)17:57, 29 August 2024 (UTC)
I have been experimenting with dark mode (&withgadget=dark-mode). While doing that, I received a "You have a new Talk page message" notification. In dark mode, I had no idea that the notification was there. The text is black on a dark brown background that visually disappears in the black window. I did not even see the light red badge on the bell. Looking at it now, the pink badge is kind of obvious but I only noticed it while looking for it after seeing the normal notification in another window with the original white background. It is essential that new editors receive an in-your-face talk notification because we block people who do not respond but continue with problematic editing. I know this should be requested elsewhere but there is not much point adding the opinion of one person so I'm looking for thoughts. Johnuniq (talk) 05:07, 30 August 2024 (UTC)
Not via the WEBUI, you may get close with the API - but a quarry report is likely going to give you what you want assuming your filters are supported cheaply. — xaosfluxTalk18:26, 27 August 2024 (UTC)
Another possibility is old-school screen scraping. Just go to your contributions page in a browser and save the page as HTML (in Chrome, it's File/Save Page As..., and I'm sure similar in most other browsers). Then hack at the HTML with standard command-line tools. This did a pretty good job for me:
It's ugly and hackish, but for a one-off job where you can accept occasional errors, it's often the best way. If you're not into the command-line, google for "HTML to CSV conversion" and you'll find lots of other tools that do this. RoySmith(talk)15:22, 29 August 2024 (UTC)
I use Notepad++ + regex. I copy the list into Np++, use Alt to column-select all the text to the left of the page names & remove it, then Ctrl+H to remove diffhist [^\r\n]+, leaving only the page names. ~Tom.Reding (talk ⋅dgaf)16:23, 29 August 2024 (UTC)
Thank you, Tom.Reding (and all) that's an interesting approach. But the recent results for my contribution include:
12:02, 26 August 2024 diff hist +32 N De Cotiis #REDIRECT Vincenzo de Cotiis current Tags: New redirect Uncategorized redirect
18 August 2024
18:59, 18 August 2024 diff hist +32 N Taxa inquirenda Species inquirenda current Tags: New redirect Uncategorized redirect
7 August 2024
22:04, 7 August 2024 diff hist +31 N Jablochkoff electric candle #REDIRECT Yablochkov candle current Tags: New redirect Uncategorized
and not only does your regex not work for that (it removes the page titles as well as other stuff), but the "diff hist" columns do not align, as the dates are of differing lengths. Are we at cross purposes? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits14:14, 30 August 2024 (UTC)
The 2 apparently empty brackets [ ] actually contain 2 whitespace characters each, present in sample text, 1 of which is 0-width, so be careful when copy-pasting, since misplacing and/or losing the 0-width character is never good.
There are 3 whitespace characters in (?: ), which are also required.
The position & formatting of diff hist/diffhist probably differs based on skin, but the idea is to use some string that appears at the same relative position on each line.
Make sure there is a blank line before the first line, to match (\r?\n), which are the CRLF characters, or else the regex won't evaluate the first line.
What Izno said. Or, to save you the trip, here's a list going back to late June 2018 (when the create log began). I've removed creations in user talk, too, since I assumed that's what you meant; there were 585 in that namespace, compared to just 21 in User:. CSV available in the cyan "Download data" box. —Cryptic14:46, 30 August 2024 (UTC)
Problem of using "|show_designation=no" and "|show_type=no" on Template:Public art row
Hi
I am trying to use "|show_designation=no" and "|show_type=no" commands on Template:Public art row when I use the template on list of public art pages, but it keeps showing these colons.
The simple answer is that these parameters are not recognised or supported by Template:Public art header. Perhaps it was thought that every table should have these columns. Are you sure it is appropriate to omit them in the article you are working on? — Martin (MSGJ · talk) 06:36, 31 August 2024 (UTC)
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) 12:41, 31 August 2024 (UTC)
Xtools appears to be down
Here - it says 'Error' and then "This web service cannot be reached. Please contact a maintainer of this project. Maintainers can find troubleshooting instructions from our documentation on Wikitech." Any idea what's going on? GiantSnowman13:43, 31 August 2024 (UTC)
I'm not familiar with Phabricator and I'm not sure it's the best place to point this out. I made this edit. It appeared on the page after I clicked on the button to publish. As I clicked back to where I was before, the edit disappeared. It was gone from the live page and also gone when I clicked the edit button to browse the page's text, this without any intervention via succeeding edits. This continued to be the case after I cleared the cache for the page. However, the edit was still there when I checked the page's edit history and my own contribution history. I thought this to be bizarre, as I don't recall anything like this ever happening before. RadioKAOS / Talk to me, Billy / Transmissions 20:14, 31 August 2024 (UTC)
I would like to request a tool that, given a revision number (or title) of a page and timestamps T1 and T2, would run down all the transcluded templates, {{excerpt}}s, and modules in that rev, and return a most-recent-first sorted list of transcluded/invoked items which have changes recorded in their history between T1 and T2, or since T1 (if T2 is empty). The tool should recursively expand templates (maybe only if |recurse=y?). Possible format: four columns, with 1) Item name, 2) last change timestamp, 3) rev. number, 4) userid; where item name could be template, module, or excerpted source pagename. Bonus: column five, containing the template traceback sequence, if the row item was not found at top level, i.e., the item was not directly transcluded by the given page rev., but further down.)
Here is my use case: I recently panicked when I noticed that Ships of ancient Rome, which has over one hundred {{sfn}} short citations and makes liberal use of {{excerpt}} had fifty harv errors of the type 'Harv error: link from CITEREFLastname-YYYY doesn't point to any citation'. (I am very familiar with sfn/Harv errors of this sort and how to fix them, and wrote part of the doc for it; ditto {{excerpt}} doc.) The offending edit was a very minor change to add a {{convert}} template to the body (diff) which resulted, very oddly, in the 50 errors. No one had changed {{convert}} or Module:Convert, so I first suspected PEIS issues or nonprinting characters, but that proved wrong, and the problem went away during the time I worked on it (see these 6 edits), so I presume an upstream problem had been fixed in the interim. It could have been an entirely different template, but my investigation was hampered, and then I abandoned it, because of the impracticality of tracking down every transclusion made by the article, possibly recursively if nothing changed in directly transcluded items.
Having a tool that would return a sorted list of most recently changed transcluded items would be a powerful aid in this situation. (O/T: we need a word that encompasses the meanings of transcluded, invoked, or excerpted; I vote for eval'ed unless somebody has a better idea.)
The way things turned out, the problem I observed (whatever the cause) was fixed while I looked into it, and that's great, but what if it hadn't been? Such a tool would be very useful to help someone track down a real problem and make it possible to find and advise the author of a recent change that broke something, whereas now, it is so impractical as to be near hopeless. Can anyone build this? (edit conflict) Mathglot (talk) 21:04, 31 August 2024 (UTC)
Sounds a lot like Special:RecentChangesLinked, except substituting the templatelinks table for pagelinks, only going in one direction, and without the unfeasible complication of looking at old revisions instead of the current one. I'm surprised it's not in MediaWiki already (and wouldn't be surprised if it was and I just didn't know where to find it). Twenty years ago I'd have suggested making a feature request. For now, something like quarry:query/85974 is probably the best you can hope for. —Cryptic21:43, 31 August 2024 (UTC)
template/technique request : insert wikitext between each character of string
resolved
i am looking for something that works like the following two examples ; between abc → a;b;c {{key| followed by }}{{key| between abc followed by }} → abc
thanks in advance akizettalk20:34, 1 September 2024 (UTC)
A while ago, I asked about references. I put that aside for a while and now I'm picking it up again. It's obvious that my original strategy was not going to work, so I'm starting again. Before I dive into this too deeply, is there any actual documentation on how references are rendered in HTML? Some of it I can suss out. For example, the first citation in Special:Permalink/1233803324 gives:
in the reflist, with the backlink for citation 1a, and I should treat the "cite_ref..." and "cite_note" ids as opaque strings (as opposed to trying to parse them, as I was originally doing). Is that it, or are the more bits of magic that will only become apparent when this iteration of my code breaks on something I haven't seen yet? RoySmith(talk)19:26, 31 August 2024 (UTC)
There is no documentation on the current parser's format, but there is documentation for the new parser: https://www.mediawiki.org/wiki/Specs/HTML/Extensions/Cite. You will probably have a much more enjoyable time working with the new parser's output anyway, since it includes lots of extra output to make it more machine-readable (e.g. the values for refname in the data-mw attribute – no need to try to parse them out of the href/id).
It's somewhat vestigial. For other wikitext XML-style tags, and for template transclusions, it's used to mark all of the HTML tags that were generated by that wikitext tag or template. But since every wikitext <ref> corresponds to exactly one HTML <sup>, the attributes don't provide any extra information. This is mentioned at https://www.mediawiki.org/wiki/Specs/HTML#DOM_Ranges, but it could be documented better… Matma Rextalk21:32, 1 September 2024 (UTC)
it's used to mark all of the HTML tags that were generated by that wikitext tag or template Wow, that's (in the general case) really useful. I've often looked at the pile of HTML in my browser and tried to figure out what generated it. Now I know! RoySmith(talk)22:48, 1 September 2024 (UTC)
Am I imagining that until today I could hide/unhide diffs in my watch list?
@PrimeHunter Thanks. I'm afraid I am not sure how to add that to my global.js - or how to load the other one in my browser console. In fact, I'd never heard of my browser console until today. I use Chrome and have found it now, but am still pretty clueless. Sorry. Doug Wellertalk08:06, 1 September 2024 (UTC)
@PrimeHunter I copied mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Writ Keeper/Scripts/commonHistory.js&action=raw&ctype=text/javascript"); into the console and hit return but got the message "undefined". Doug Wellertalk10:27, 1 September 2024 (UTC)
Not sure if it is relevant, but I've 3 watchlists, one for user and user talk pages, one for articles and their talk pages, the third for Wikipedia and Wikipedia talk, and that one has show and hide diffs. I'm not sure if that's always been the case, sorry. Doug Wellertalk10:32, 1 September 2024 (UTC)
Adding an EventListener to avoid unwanted submit during type of "edit summary" textboxes
Hi, for example during type of "edit summary" after an edition or during writing "Other/additional reason" for moving a page, users may press enter button, but they may or may not tend to submit their form. In the case of not tending to submit their form, this behavior of Wikipedia may be considered ill-posed. For example consider this scenario:
During the third stage, casual pressing enter key may lead to ill-posed submit of this form. So, I propose adding this EventListener to avoid wrong submit:
Or somehow showing a confirmation message box, like this:
varinput=document.getElementById("myInput");input.addEventListener("keypress",function(event){if(event.key==="Enter"){lettext="Are you sure?";if(confirm(text)==true){document.getElementById("myForm").submit();}}});
I myself have had many problems with this «default behavior of forms on in HTML». This behavior is not the intended behavior for such important actions like "Edit" and "Move" of pages. I really think that other users of Wikipedia sometimes have had many problems with this default behavior.
This default behavior is good for other applications, like entering a password and then checking it on back-end code.
I really think that showing a confirmation before publishing an edit (only showing confirmation in the case of pressing Enter key in the textbox, otherwise not showing) would be helpful. Hooman Mallahzadeh (talk) 12:14, 1 September 2024 (UTC)
As you can see Hooman, many experienced editors are very used to being able to press Tab and then Enter to quickly save their edits ;) even though it causes mistakes sometimes (I've seen many edit summaries cut off because someone pressed Enter instead of an apostrophe).
For what it's worth, other editing interfaces actually show a confirmation message when pressing Enter, and require Ctrl+Enter to actually submit the edit. This was implemented in the visual editor (where the edit summary field appears multi-line, so trying to press Enter to input a line break would be a common mistake) and in the reply tool (the edit summary is hidden under "Advanced" – there was some discussion about that behavior at the time at T326500). Matma Rextalk21:43, 1 September 2024 (UTC)
And in the CAPTCHA confirmation menu for the reply tool, which might be a side-effect? Thankfully it doesn't happen often, I'm not a fan of needing to press Ctrl+Enter there.
Do you have a certain use-case in mind? And especially, is this something for mainly personal convenience or a tool you might share, or instead is it for something you are developing for wider adoption/generally used template-tags? DMacks (talk) 21:48, 1 September 2024 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
Editors and volunteer developers interested in data visualisation can now test the new software for charts. Its early version is available on beta Commons and beta Wikipedia. This is an important milestone before making charts available on regular wikis. You can read more about this project update and help to test the charts.
Feature news
Editors who use the Special:UnusedTemplates page can now filter out pages which are expected to be there permanently, such as sandboxes, test-cases, and templates that are always substituted. Editors can add the new magic word __EXPECTUNUSEDTEMPLATE__ to a template page to hide it from the listing. Thanks to Sophivorus and DannyS712 for these improvements. [6]
Editors who use the New Topic tool on discussion pages, will now be reminded to add a section header, which should help reduce the quantity of newcomers who add sections without a header. You can read more about that, and 28 other community-submitted tasks that were resolved last week.
Last week, some Toolforge tools had occasional connection problems. The cause is still being investigated, but the problems have been resolved for now. [7]
Translation administrators at multilingual wikis, when editing multiple translation units, can now easily mark which changes require updates to the translation. This is possible with the new dropdown menu.
Project updates
A new draft text of a policy discussing the use of Wikimedia's APIs has been published on Meta-Wiki. The draft text does not reflect a change in policy around the APIs; instead, it is an attempt to codify existing API rules. Comments, questions, and suggestions are welcome on the proposed update’s talk page until September 13 or until those discussions have concluded.
Learn more
To learn more about the technology behind the Wikimedia projects, you can now watch sessions from the technology track at Wikimania 2024 on Commons. This week, check out:
Does anyone know how we can get the new keyword into the automatic "This is the template sandbox page for..." note that appears on template sandbox pages? – Jonesey95 (talk) 04:15, 3 September 2024 (UTC)
@Rusalkii: Do you mean the box with the rows having differently-coloured backgrounds, or the list below the heading 'Pages in category "Wikipedia conflict of interest edit requests"'? They have different origins.
The second one is the primary list, it is driven directly by the use of the {{edit COI}} tag (with no parameters, or with certain param values) on a talk page, and it should update at the exact moment that you save an edit that adds e.g. |D or |answered=yes to the tag.
If you mean the box, it's transcluded from User:AnomieBOT/COIREQTable which is built periodically by AnomieBOT (talk·contribs). I would not expect this to update instantaneously, a delay of minutes or hours is not uncommon. If AnomieBOT is not updating the page, that's a matter for the bot operator, i.e. Anomie (talk·contribs), but please read the bot's User: and User talk: pages before raising what might be a duplicate complaint. --Redrose64 🌹 (talk) 07:26, 3 September 2024 (UTC)
I'm a long time editor. Throughout my career, I have used Safari. I am not updated to the most recent OS because my computer cannot handle it. I have no problem editing in mainspace. However when I make an edit to a talk page (even this page), if I move my cursor, the next capital letter will jump the cursor to the first character of the edit box, meaning I have to go back to move all sentences through cut and paste. It's obnoxious. It makes it hard to concentrate when so many sentences now constructed in reverse order need to be moved.Trackinfo (talk) 19:40, 2 September 2024 (UTC)
I just tried to fix a few examples and it's taking way too long. As a busy practicing attorney, I don't have two hours to spare to clean up someone else's mistakes. I have better things to do with the Labor Day holiday weekend, like going through more of my photography library to identify more photos for upload to Commons.
One of the longest running debates among lawyers for many centuries is whether a trial court should be organized as a nationwide or statewide entity that merely happens to sit in multiple counties, districts, or circuits—or whether each county, district or circuit should be regarded as having an entirely separate trial court. There are strong public policy arguments for and against each position, resulting in worldwide gridlock on this issue.
California is among the majority of American jurisdictions that adhere to the latter position. In other words, it has 58 superior courts, not one superior court that happens to sit in 58 counties. Section 1 of Article 6 of the California Constitution refers to "superior courts" (notice the plural) and Section 4 starts with the following words: "In each county there is a superior court of one or more judges."
Unfortunately, User:Mliu92 created many articles for superior courts that imply that California adheres to the former position. For example, the article for Santa Cruz County Superior Court incorrectly states that the "Superior Court of California, County of Santa Cruz, is the branch of the California superior court with jurisdiction over Santa Cruz County."
We need a bot to go through the English Wikipedia and replace every instance of the phrase "is the branch of the California superior court" with the phrase "is the California superior court". How do I go about initiating that request? Coolcaesar (talk) 19:11, 31 August 2024 (UTC)
Coming soon: A new sub-referencing feature – try it!
Hello. For many years, community members have requested an easy way to re-use references with different details. Now, a MediaWiki solution is coming: The new sub-referencing feature will work for wikitext and Visual Editor and will enhance the existing reference system. You can continue to use different ways of referencing, but you will probably encounter sub-references in articles written by other users. More information on the project page.
We want your feedback to make sure this feature works well for you:
Sign up here to get updates and/or invites to participate in user research activities.
We are aware that enwiki and other projects already use workarounds like {{sfn}} for referencing a source multiple times with different details. The new sub-referencing feature doesn’t change anything about existing approaches to referencing, so you can still use sfn. We have created sub-referencing, because existing workarounds don’t work well with Visual Editor and ReferencePreviews. We are looking forward to your feedback on how our solution compares to your existing methods of re-using references with different details.
Wikimedia Deutschland’s Technical Wishes team is planning to bring this feature to Wikimedia wikis later this year. We will reach out to creators/maintainers of tools and templates related to references beforehand.
This is a very important task to work on, but I am not sure how this proposal is an improvement for those of us who do not use the VisualEditor.
Compare:
<refname="Samer M. Ali">Samer M. Ali, 'Medieval Court Poetry', in ''The Oxford Encyclopedia of Islam and Women'', ed. by Natana J. Delong-Bas, 2 vols (Oxford: Oxford University Press, 2013), I 651-54.</ref>{{r|Samer M. Ali|p=653}}
or:
<refname="Samer M. Ali"/>{{rp|653}}
with:
<refname="Samer M. Ali">Samer M. Ali, 'Medieval Court Poetry', in ''The Oxford Encyclopedia of Islam and Women'', ed. by Natana J. Delong-Bas, 2 vols (Oxford: Oxford University Press, 2013), I 651-54.</ref><refextends="Samer M. Ali"name="Samer M. Ali, p. 653">p. 653</ref>
existing workarounds don’t work well with Visual Editor and ReferencePreviews OK, then VE and ReferencePreviews need to be fixed so that they work well with the existing ways of referencing.
Adding another competing standard (obligatory XKCD) is not very useful unless you want to disallow the others which will probably make people very mad (see WP:CITEVAR) and is not necessarily an improvement.
There is no reason why VE or RP would require a new standard, they could just as easily support one of the existing ones (and ideally all of em).
Sfn is routinely out of sync with its parent and requires the use of third party scripts to detect that it is so. Extended references do not i.e. the Cite extension will issue a warning when you have an extension without a parent.
And Rp is objectively subjectively ugly. Presenting it as a potential option is offensive. :)
In <refextends="Samer M. Ali"name="Samer M. Ali, p. 653">p. 653</ref>, a name for the subreference is not required (<refextends="Samer M. Ali">p. 653</ref> will be typical I suppose), and even when it is you can abbreviate since you know what the parent is (e.g. <refextends="Samer M. Ali"name="SMA653">p. 653</ref>).
Some other benefits:
Reference extensions work with reference previews to display the extension directly with the primary citation.
The extensions are grouped with the primary citation in the reference lists.
And the third, which you brushed aside: VE works well with reference extensions.
And as for OK, then VE and ReferencePreviews need to be fixed so that they work well with the existing ways of referencing., MediaWiki systems try to be agnostic about the specific things that wikis do around X or Y or Z. As a general design principle this helps to avoid maintaining systems that only some wikis use, and leaves the burden of localization and each wiki's design preferences to those wikis. Rp additionally has nothing to work with in regard to VE and ref previews. Izno (talk) 16:06, 19 August 2024 (UTC)
@Izno: Thank you. Gotta sell these things a bit, you know?
Is this style of referencing intended to replace all others? If its better, then lets just abandon all other variants.
The extends keyword is familiar to codemonkeys but perhaps not the most userfriendly for others. I am not sure why it would be harder to show an error when someone writes <refname="nonexistant"/>{{rp|653}} than when someone writes <refextends="nonexistant">p. 653</ref> but in theory this new system could auto-repair references (has that been considered?) Category:Pages_with_broken_reference_names contains 1300+ pages.
I agree with Izno—I'd rather have a syntax that integrates with the <ref>...</ref> syntax, rather than relying on templates, which mixes in a different syntax, and are wiki-specific. isaacl (talk) 16:28, 19 August 2024 (UTC)
If you control the parser you can make any string do anything you want so the currently chosen syntax is, in itself, no advantage or disadvantage. Polygnotus (talk) 16:31, 19 August 2024 (UTC)
You provided the wikitext for two examples and asked if one seemed to be an improvement, so I responded that in my opinion, the syntax of the sub-referencing feature under development is conceptually more cohesive to an editor than one where wikitext surrounded in braces follows the <ref.../> code, or uses solely wikitext surrounded by braces. Sure, any strings can be turned into any other strings, but there are still advantages of some input strings over others. I also prefer the resulting output of the reference list. isaacl (talk) 16:45, 19 August 2024 (UTC)
Agreed, but I assume that things are not set in stone yet. I don't mind the difference between [1]:635 and [1.1] or what exact wikicode is used. So I am trying to think about functionality (e.g. automatically repairing broken refs/automatically merging refs instead of how things get displayed/which wikicode is used). Polygnotus (talk) 16:47, 19 August 2024 (UTC)
I apologize as your first post seemed to be concerned about the wikitext markup being used by users of the wikitext editor. From a functionality perspective, I think as Izno alludes to, it will be easier to implement features such as detecting hanging references and merging them together with a syntax that is within the <ref> element, rather than relying on detecting templates and associating them with <ref> elements. That would require the MediaWiki software to treat some wikitext in double braces specially. (It would be easier if the extended information were flagged using triple braces, since it would avoid clashing with the extensible template system, but I don't see any advantages to that over extending the <ref> syntax.) isaacl (talk) 17:09, 19 August 2024 (UTC)
Please don't apologize to me (even if there would be a reason to do so, which there isn't), I am a very confused and confusing person and I understand myself roughly 4% of the time (and the world around me far less often than that). Polygnotus (talk) 17:14, 19 August 2024 (UTC)
Good to see this moving forward. My main interest was how it would look on the hover, rather than in the References section. I thought the ref extends might 'fill in' variable fields into the general ref, but it seems instead that it just created a new line below. How flexible is this below line, will it display any wikitext? Could we for example add chapters and quotes? (Which will need manual formatting I assume.) CMD (talk) 16:53, 19 August 2024 (UTC)
What parameters should be sub-referenced? It should be limited to page numbers, and quotes. Not, for example, multiple works, authors, volumes, issues, IDs, dates of publication, ISBN numbers, etc..
How is data in a sub-ref added? If it's free-form text, it's a step backwards from CS1|2's uniform |page=42 to a free-form text like "Page 42" or "(p) 42" or whatever free-form text people choose. Bots and tools need to be able to parse the page number(s). Free form text is not semantic. Templated text is semantic. Anything that moves from semantic to non-semnatic is bad design.
Before this is set loose, there must be consensus about how it should be used. It opens an entirely new dimension to citations that is going to impact every user, citation template, bot, bot library (PyWikiBot etc), tool, etc.. -- GreenC17:00, 19 August 2024 (UTC)
Yeah its also a bit weird to ask for feedback and then already have a proof of concept and say is planning to bring this feature to Wikimedia wikis later this year. You must ask for feedback before code is written and before any timeline exists. Polygnotus (talk) 17:05, 19 August 2024 (UTC)
At a minimum, it should not be added until there are clear guidelines for usage. More specifically, it should have a feature that issues a red error message if the sub-ref does not contain a special template for displaying page numbers and/or quotes ie. anything else in the sub-ref is disallowed. Then new parameters can be added once consensus is determined. We should have the ability to opt-in parameters, instead of retroactively playing cleanup removing disallowed parameters. -- GreenC17:18, 19 August 2024 (UTC)
@GreenC: So then you would get something like this, right?
<refextends="Samer M. Ali"page=""chapter=""quote=""anchor=""><refextends="Samer M. Ali">{{subref|page=""|chapter=""|quote=""|anchor=""}}</ref>
And then a form in VE where people can fill it in.
The former was deliberately not chosen during design work as being too inflexible for all the things one might want to make an extending reference. Izno (talk) 19:33, 19 August 2024 (UTC)
"All the things", which below you said was only page numbers, chapters and quotes. What else do you have in mind? -- GreenC20:04, 19 August 2024 (UTC)
There have been previous requests for support in CS1 for subsections of chapters of works. But that's beside the point: we don't need to lock this down out of some misbegotten idea of chaos. YAGNI. Izno (talk) 20:45, 19 August 2024 (UTC)
It will be chaos as currently proposed, though I never said "lock this down". Johannes asked for feedback. The two main issues I raised, Johannes already said, these are known issues. He said, make a guideline. So I suggested at a minimum, let's make a guideline. You and Johannes don't seem to be on the same page about that. You hinted that were part of the development team, is that correct? -- GreenC23:09, 19 August 2024 (UTC)
No, I am a volunteer interested in this work since when it was first discussed at WMDE Tech Wishes and/or the community wishlist and have been following it accordingly, working on a decade ago now.
Guidelines are descriptive also. "We usually use it for this, but there may be exceptions." is reasonable guideline text. "You are required to use it only for this." is another reason it's not going to fly. Izno (talk) 16:06, 20 August 2024 (UTC)
That's a shame, the former was precisely what I imagined and was excited for when I first read about the idea. CMD (talk) 02:36, 20 August 2024 (UTC)
@GreenC We don't do that with regular references. There's nothing in the software that produces a red error message if I do <ref>My cousin's roommate's friend told me</ref>, so why should subrefs be enforcing that? --Ahecht (TALK PAGE)19:37, 19 August 2024 (UTC)
@Polygnotus: This has been being discussed for many years now. m:WMDE Technical Wishes/Sub-referencing was created in 2018, and even then the idea had already been being discussed for a while. phab:T15127 was created in 2008. It's not odd that they're finally at the stage of having an implementation (or if it is, it's that it took so long to get here). Anomie⚔21:45, 19 August 2024 (UTC)
You should probably assume that's the situation for any MediaWiki change. A few years back, some user script authors were mad because a code change had been throwing error messages at them for "only" seven years(!), which was obviously too short a time frame for them to notice that anything needed to be adjusted. WhatamIdoing (talk) 23:06, 23 August 2024 (UTC)
I actually totally disagree and think you're making a mountain out of a molehill. My anticipation is that most people will use it for the obvious (page numbers). In some cases they may use chapters (a single long text with a single author or even for anthologies). Rarely do I anticipate them using anything else, but I think they should have the luxury of putting whatever they want in the reference.
As regards mandating some use like templates, that's not how it works, though I can imagine some sort of {{Cs1 subref}}... which is probably basically {{harvnb}} and some others.
One thing however that is sure not to occur is to have subreferences of subreferences. This should prevent the vast majority of pathological cases. Izno (talk) 19:32, 19 August 2024 (UTC)
Uh, yeah. People have successfully used our current mechanisms for extending a parent reference in many many ways which notably don't fit what you want. Izno (talk) 20:44, 19 August 2024 (UTC)
/me looks back 20+ years… sure is a good thing we wrote all those guidelines before making a wiki that was to become the most popular encyclopedia……. —TheDJ (talk • contribs) 07:20, 20 August 2024 (UTC)
No one's stopping you from writing some guidelines. There might not even be any opposition if you put sensible things in it. But as Izno says, the guidelines would be advisory rather than prescriptive. – SD0001 (talk) 14:03, 20 August 2024 (UTC)
When a document has a nested structure, e.g., chapters within sections, it is natural for an editor to want citations that match that structure. I would expect nested citations to include arbitrary combinations of author, editor, page, quote, title and URL, depending on the type of document. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:15, 19 August 2024 (UTC)
Does "will work for wikitext and Visual Editor" cover the list-defined references examples on the demo page? I'm testing right now and the Visual Editor still seems to have the same problems with list-defined references that have existed for some time.[9] Will this update fix any of those issues? Rjjiii (talk) 02:28, 20 August 2024 (UTC)
Hi, thanks for your feedback, questions and interest in sub-referencing! Given the large number of comments, I’ll try to provide answers to all of them at once:
replacing other referencing styles: We don’t intend to replace other citation styles. We are fulfilling an old community wish, creating a MediaWiki solution for citing a source multiple times with different details. Citation styles are a community matter and per WP:CITEVAR you can continue to use your preferred way of referencing. If the community wants certain referencing templates to be replaced by sub-referencing, they are of course free to do so, but that’s up to you.
Reference Previews are going to display both main- and sub-reference in one reference pop-up, showing the sub-reference’s details below the main information (example). There are still a couple of details going to be fixed in the next couple of months.
ReferenceTooltips (the gadget enabled by default at enwiki) will need an update. It currently only displays the sub-reference’s information (example), similar to the behavior with sfn (example). But different to sfn (example) it currently doesn’t show a pop-up on top of the first pop-up for the main information. Given that gadgets are community-owned, we won’t interfere with that, but we’ll try to assist communities in updating the gadget.
Yes it will be possible to display any wikitext in sub-references, just like it is possible to do so using normal references (without any templates). We’ve intentionally allowed this, because local communities prefer different citation styles (and even within communities users have different preferences), therefore our solution shouldn’t limit any of those. Citing sources with different book pages will probably be the main reason to use sub-referencing, but it’s also possible to use it for chapters, quotes or other details.
You’ll need to do the formatting (e.g. writing details in italic) yourself, except if the community creates a template for sub-references
List-defined references in VE: We are aware of the issues mentioned in phab:T356471, many of those also affect sub-references. As we are still defining some VE workflows (currently we’ve mostly worked on the citation dialog) we haven’t found a solution yet, but we might be able to resolve at least some of those issues while continuing our work on sub-referencing in Visual Editor.
As already mentioned on meta this should be up to local communities, given the many different referencing styles. It should also be up to them to decide if they want to use templates for sub-referencing or not. We’ve reached out to communities much in advance, so you should have enough time working out some guidelines if your community wants that.
But as Ahecht said: Users can already use references for all kinds of unintended stuff, sub-referencing is not different to that. It’s necessary to technically allow all kinds of details in sub-references, due to the many different citation styles within one community and across different communities.
From our user research we expect most people using sub-referencing for book pages. There will be a tracking category (example) which could be used to check if there is unintended usage of sub-referencing
Adding another referencing style isn’t really useful: We are fulfilling a wish which is more than 15 years old and has been requested many times in the past years. Existing template-based solutions for citing references with different details only work on those wikis who maintain such local templates – and most of those have issues with Visual Editor. That’s why a global MediaWiki solution was necessary. You can always continue to use your preferred citation style per WP:CITEVAR.
Doesn’t look like an improvement for Wikitext: If you compare it with template-based solutions like {{rp}} you are correct that those allow for simpler wikitext. But if you’re editing in multiple Wikimedia projects, your preferred template from one project might not exist on the other one. That’s why a MediaWiki solution will be beneficial to all users. And most current template-based solutions have the already mentioned disadvantages for Visual Editor users. Also readers will benefit from a more organized reference list by having all sub-references grouped below the main reference.
The attribute “extends” doesn’t seem user friendly for non-technical users: We’ve done several consultations with the global community and a lot of user testing in past years where we asked for feedback and ideas on the attribute name. One takeaway is that the name is less important for many users than we initially thought, as long as they can remember it. And our user tests showed a surprisingly large number of Wikitext users switching to VE in order to use the citation dialog (for referencing in general, not just for sub-referencing) – if you do that, you don’t need to deal with the attribute name at all. We didn’t see any major issues with “extends” for people exclusively using Wikitext in our user tests. But so far there is no final decision on the attribute name, so if you have any ideas let us know (we’ll make a final decision soon).
You should have asked for feedback earlier: We’ve been working on this feature (on and off) for almost 8 years and had a lot of community consultations (e.g. at Wikimania, WikiCite, discussions on metawiki where we invited communities via Mass Message) and many rounds of user testings – always with the involvement of enwiki users. And we are doing this big announcement now in order to make sure that really everyone knows in advance and can provide further feedback while we are finalizing our feature.
Perhaps it would be wise, in future, to make a list of predictable reactions/questions and incorporate the responses to those in the announcement. Highlighting the advantages of a change/addition, USPs if any, why decisions were made and perhaps even a short timeline can make the reception much warmer. Some people here (e.g. Polygnotus) don't know the 15 years worth of background information. The good news is that I think that it is an improvement (although it could be a bigger improvement). I assume others have also mentioned things like ensuring refs don't break and automatically merging refs (but I do not want to dig through 15 years of history to figure out why it wasn't implemented) and this is/was an opportunity to make something superior to the existing methods that could replace them. The OrphanReferenceFixer of AnomieBOT will need to be updated. Polygnotus (talk) 17:04, 20 August 2024 (UTC)
It's always difficult to write such announcements in a way that they answer the most important questions while also being short an concise so that people actually read the them ;) Some of the questions raised in this section have already been answered in meta:WMDE Technical Wishes/Sub-referencing#FAQ and we'll continue to add more frequently asked questions there, if we notice (e.g. in this village pump discussion) that certain questions come up again and again. Johannes Richter (WMDE) (talk) 17:16, 20 August 2024 (UTC)
Agreed, it is super difficult to strike the right balance. And even if you do, some will still be grumpy. But its also very important. Polygnotus (talk) 17:20, 20 August 2024 (UTC)
Thanks for the detailed response and the included screenshots. I was a bit glum following my comment above but I think I have a better grasp of the underlying concept now. If we are able to use citation templates in the sub-reference field, that may provide a way to fix at least some of the potential issues raised above. Is there a place to track changes to the reference pop-up (File:Sub-referencing refpreview.png)? My first impression is that's perhaps not a necessary large white space but I'm curious to read more discussion on the matter. CMD (talk) 17:25, 20 August 2024 (UTC)
@CMD depends on what you mean by "place to track changes"? There are several phabricator tags which might serve this purpose (although we've collected a lot of user feedback which is still under discussion and therefore not filed as a task yet). We want to use meta:WMDE Technical Wishes/Sub-referencing#Recent changes and next steps to document important changes on the current prototype and can certainly document further changes to Reference Previews for sub-referencing in this section as well, if that's what you imagined? Johannes Richter (WMDE) (talk) 15:43, 21 August 2024 (UTC)
Yes, reference previews are one of the great benefits of the Wikipedia reference system. I'll follow on meta. CMD (talk) 16:27, 21 August 2024 (UTC)
Thanks for the lengthy reply! Can a template tell if it's being used in an extended reference?
If there is any probability of this all working in the Visual Editor, we should also aim to make templates that work in the Visual Editor. That would mean a template that slots inside of an extended reference, rather than a template that invokes one (the way that {{r}} or {{sfn}} work). There is already some discussion at Help talk:Citation Style 1 about building a template for consistency between the main named reference and the extended sub-references. I considered making a proof of concept template that would only handle pages, quotations, and so on, but folks have already mentioned citing named sections in a larger work and other broader ideas.
For a template to plug into this, I've checked the parameters currently available in major templates that cite locations within a longer work. If I've missed anything feel free to update this table:
In-source location parameters in existing templates
Also, regarding formatting, CS1 and sfn are based (to an extent) on APA and Harvard citation styles.
Also(B), regarding LDR, one of the issues with list-defined references in the Visual Editor is that removing all usage of a reference from an article's body text makes the reference become invisible in the VE and emits this error message on the rendered page, "Cite error: A list-defined reference named "Bloggs-1974" is not used in the content (see the help page)." To have an un-called reference isn't exactly an error, though. Editors move citations from the bibliography and standard references down to other sections (Further reading, External links, and so on); some articles still have general references at the bottom. Is there a way to push un-called references down to the bottom of the list and treat them as a maintenance issue rather than an outright error, like the below example with citations borrowed from Template:Cite book/doc(11-02-2024)
Can a template tell if it's being used in an extended reference? No, not currently. Lua experts feel free to correct me if I am wrong. Polygnotus (talk) 02:57, 21 August 2024 (UTC)
push un-called references down to the bottom of the list and treat them as a maintenance issue it isn't even a maintenance issue; it is useful if people name refs so that those names can be used later to refer to those refs. But if no one refers to em that is fine. Polygnotus (talk) 03:01, 21 August 2024 (UTC)
Indeed to best of our knowledge templates currently cannot tell if they are being used in a sub-reference. But it should be possible to make such changes. As templates are community-owned, we cannot do that ourselves, but we'll try to assist communities (e.g. by providing documentation or some examples) with the necessary changes to citation tools and templates. Johannes Richter (WMDE) (talk) 15:47, 21 August 2024 (UTC)
Yes, additional parameters might be needed on <ref>...</ref> and on citation templates to designate main and sub-references.
LDRs that are named but not cited are most definitley treated as errors; that doesn't mean that they should be treated as errors. There are other markup languages where uncited references are treated as legitimate. Admiitedly {{Refideas}} is a workaround, but it would be nice if {{Reflist}} could include incited references and if the LDRs were listed first. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:20, 21 August 2024 (UTC)
Incategory searches missing redirects?
Wanted to ask about a recurring problem I run into occasionally when working with Wikipedia:Database reports/Polluted categories to clean up userspace content in articlespace categories. When I use each category's "search user namespace" link in that report, I will either get a list of one or more userspace pages, or the text "There were no results matching the query" — the majority of the time, the latter means that the category has already been cleaned up, either by me via another query earlier in the batch (since pages are often in more than one category at the same time) or by somebody else before I even got to it. However, on occasion there are categories on a redirect in userspace, which the search link seems to fail to detect because it's a redirect instead of a straight sandbox "article", and thus tells me that the category is already clean when it actually isn't.
So because the link failed to detect the redirect and told me that the category was clean, I just move on, but because the category isn't actually clean, that redirect just stays in the category until I notice, on a future run of that report, that the search link was purple (meaning I've visited that exact search link before) and the category is still empty — meaning that I have to take the extra step of manually eyeballing the category to see if there's a userspace redirect in it. Examples: User:Upgov.in/sandbox, which had been in categories since August 19, and User:Luis Santos24/sandbox2, in categories since August 11, meaning they both survived multiple regenerations of the report before I finally caught them today.
TLDR, the polluted categories report does catch userspace redirects, but the search link fails to find them when I use it.
However, since the majority of "there were no results matching the query" categories are actually genuinely clean, it wouldn't be a productive use of my time to consistently double-check every category whose search link produces that result across the board — so my question is whether somebody can look into ensuring that the incategory search stops failing to detect redirects so they can be caught the first time instead of loitering around for multiple regenerations of the report. Bearcat (talk) 17:51, 3 September 2024 (UTC)
Well, then, is there any other way to solve the problem besides the total non-starter "just let userspace redirects survive multiple regenerations of the report before getting caught" or the total non-starter "manually double-check every single category that came up as already empty"? Bearcat (talk) 18:07, 3 September 2024 (UTC)
Over on the article Bagar region there's a big red error showing at the top of the article, "<mapframe>: The JSON content is not valid GeoJSON+simplestyle." I've never seen this before and don't know how to fix it, so I thought I'd put it here to bring it to the attention of anyone who does know how to fix it. Suntooooth, it/he (talk/contribs) 21:04, 4 September 2024 (UTC)
When searching for the article Faya Dayi, the short description that shows up is "2021 ?'"`UNIQ--templatestyles-00000002-QINU`"'? film". Does anyone know why that would happen? It looks like something on the page ({{Infobox film}}?) is supposed to set it to "2021 film" but ends up inserting some kind of markup in the middle of the text. hinnk (talk) 09:43, 5 September 2024 (UTC)
I started typing "Space-Men" in the search bar and it suggested the Space-Men article with the strange short description of 1960 Italy?'"`UNIQ--ref-00000004-QINU`"'? film. It shows up in the page information page that way too, but not in the article's source/wikitext, so I'm not sure how to fix it. Any ideas? 28bytes (talk) 17:34, 26 August 2024 (UTC)
{{Infobox_film}} builds a shortdescription from the country. The country ends with a reference. A reference gets replaced by a strip marker, for technical reasons. But a short description doesn't have wikitext support, so the stripmarker is not automatically replaced/removed. The template that adds the automatic short description should be updated to strip the strip markers. —TheDJ (talk • contribs) 18:27, 26 August 2024 (UTC)
While my effort to fix it evidently didn't address the underlying issue, if you're going to slap my hand you could at least acknowledge that I made a good-faith effort to fix the most immediate problem that was presented in the OP, and that I made it clear in my own message that I wasn't sure that I'd really fixed it at all. I'm not sure what you're talking about with the second part of what you've said, unless you meant to say that I could have posted it there. Except that I couldn't have posted it there because I didn't know that the underlying issue was with the template, nor did the OP indicate that the issue lay with the template. DonIago (talk) 20:17, 26 August 2024 (UTC)
Not sure what this was supposed to accomplish. lets be glad some people try to make things better before complaining about their work. —TheDJ (talk • contribs) 22:00, 26 August 2024 (UTC)
After thinking more on it, I agree. Fixing the broken case as a temporary measure seems fine, not different from CSS fixes people make. I do think VPT should try to find the root cause of problems, but I don't think DonIago's change should have been reverted while the problem is not fixed.
I'm unclear if the strip markers not being detected is a larger issue, or something that needs to be coded into Template:Infobox film/short description. Nthep and DJ's comments made it seem like an easy fix, so I restored Space-Men to using the auto-generated SD so it will be as it was prior to the issue and utilize that auto SD. But if it is not an easy fix, then yes, we can implement the workaround that Doniago did. - Favre1fan93 (talk) 16:10, 28 August 2024 (UTC)
The problem is fairly common where the infobox generates a short description from values found in the infobox. Often a country is expected, but the country name turns out to be a list of countries. Often (like here) a field is expected to be a simple piece of text, but has a reference appended or includes an extra formatting template. In this case, the reference should be moved into the article text – the infobox should be only a summary of details that are present in full in the article. Otherwise, just add a manual SD like DonIago did. The sandbox is well out of date, so I assume that nobody has signed up to fix the template? If not, can we please just fix the Space-Men article? It hurts — GhostInTheMachinetalk to me18:16, 30 August 2024 (UTC)
Ah. I would have first tried {{Strip tags}}. Is that too aggressive? However, us mortals make such changes. We need somebody with superpowers to fix the infobox template for us. So, for now, I just fix individual articles as I find them — GhostInTheMachinetalk to me21:41, 30 August 2024 (UTC)
I have recently noticed that, in navigation templates (both navboxes and sidebars), on an article, that article's entry appears clickable. The entry is correctly bold black (ie not a blue link) but when hovered over it displays as a clickable black link, ie, the I-cursor becomes a pointer, though no action occurs.
For example, on Sockeye salmon, see the horizontal Salmon nav box at bottom. The entry for Sockeye salmon is correctly appearing black but seems clickable.
Similarly, on Battle of Elands River (1900), see the Transvaal Front vertical side campaign box. The article's entry rightly appears black but seems clickable.
How do you add extra language links to an article these days? The link now says "No languages yet." (untrue) and gives options to "Translate this page" (not what I want) and "Open language settings" (not what I want). I used to just give an option to add another link. I can do this on the other languages but not on the English Wikipedia. Hawkeye7(discuss)09:57, 5 September 2024 (UTC)
Which article? I can see "Add languages" then "Edit interlanguage links" which goes to wikidata where can enter names of articles in other languages. If the article isn't linked to Wikidata yet can do it manually or wait for it to be linked. Indagate (talk) 10:15, 5 September 2024 (UTC)
Article only created yesterday and it can take time for Wikidata to be updated, just need to give it time or do it manually. Indagate (talk) 11:42, 5 September 2024 (UTC)
I have never added languages in Vector 2022 so I don't know how it's supposed to work but I cannot find a way to do it if there are no languages or Wikidata item. I picked Mayank Vahia at Special:NewPages. The top right says "Add languages" but it only gives a search box which does nothing no matter what I try, and the options "Translate this page" and "Open language settings". They don't appear to have a way to add a language. Are you saying it's meant to not work for new pages? It would be awful design to give users an "Add languages" link which cannot add languages. PrimeHunter (talk) 11:47, 5 September 2024 (UTC)
I tried going to Wikidata ... but I should never have to go there. When you use the "Edit links" feature, you are always taken to Wikidata: that is the way that interlanguage links are always added, ever since Wikidata was launched in early 2013. --Redrose64 🌹 (talk) 17:39, 5 September 2024 (UTC)
Although your English Wikipedia account was created in June 2005, almost three years before WP:SUL came in, nowadays you should be automatically logged in on all other WMF wikis, including Wikidata. --Redrose64 🌹 (talk) 19:26, 5 September 2024 (UTC)
That stopped working a while ago. What I meant though, was that I opened a new tab, put in the URL of Wikidata, and logged in there to look at what was going on. I don't normally touch Wikidata because I lack expertise. Hawkeye7(discuss)07:07, 6 September 2024 (UTC)
Looking at other new articles, they have the same poor drop down box, but with a third option "Edit interlanguage links". Unfortunately, this takes you to Wikidata, which we don't want. In my case, it could not find the Wikidata item (although it existed), so (incorrectly) did not offer the option at all. Hawkeye7(discuss)11:59, 5 September 2024 (UTC)
The link is somewhat hidden, but you can find "Add interlanguage links" (or "Edit interlanguage links") in the sidebar, under "Tools". Matma Rextalk13:29, 5 September 2024 (UTC)
74,841 + 168 = 75,008 ?
I have a script that runs whenever I start up or shut down my laptop.
I created the script quite a while back to experiment with the Wikipedia API, and have generally ignored it since.
The script records in a log file, my Wikipedia edit count and the number of edits so far today.
It also checks the running total — does the edit count at the end of yesterday + the edits today = the edit count for the end of today?
When the total fails to match, it indicates that some edits have been "lost" because a page that I edited today was deleted during the day.
Fair enough, if I am motivated, I can look up the page for which the edits were lost — even if I now cannot see my own edit summaries.
Today, however, the script alerted me to a mismatch in the other direction.
At the end of 3 September, my edit count was 74,841
During 4 September I made 168 edits
My edit count at the end of 4 September was reported as 75,008
Now, call me picky, but I think the total should be 75,009.
Replag is zero, and edits today are being correctly counted (although the grand total is still out by one).
While inexact edit counts is not a cosmic catastrophe, I am offended when maths seems to break.
Increasing the edit count is a separate step after saving the edit, and occasionally it can fail. I had a look for related issues in Phabricator, and apparently there's an issue known as T369461 that occurs about 30 times per day, preventing some edits from being counted. Maybe one of your edits was among the unlucky ones.
There are also some actions that create edits, but don't increase an edit count. Moving a page with a redirect creates two revisions (one on each title), but only counts as one edit. Protecting a page creates a revision, but doesn't count as an edit. It doesn't seem like you moved any pages yesterday though: Special:Log/move/GhostInTheMachine (but you did today, so you might see a new discrepancy).
Also, revisions imported from another wiki will show up in your contributions, but won't be counted. Did you know that on German Wikipedia, you have 10 edits, but your edit count is 1? They usually import the history of pages when translating them. That's not what happened here, given Special:Log/import, just mentioning it as a curiosity.
Thanks for the info. So it is possible that anybody's overall edit count could be short by a small number of edits. I suspect that I could conjure a query to derive a "better" version of my count from the revision table (and the archive table?). Maybe a project for a rainy day ...
Figured this would be the place to see if anyone knows what's going on. Historically, Wikipedia:Redirects for discussion has been a rather expensive page, processing-wise, But what is currently going on has not happened at any point recently. The bottom-most sections are appearing as links instead of sections. This was not the case a few weeks ago. Does anyone know what's going on? Steel1943 (talk) 22:29, 4 September 2024 (UTC)
It's been categorized as >2,000,000 PEIS since 01:00, 2 September 2024 [11] and as >500 expensive parser calls since 02:28, 2 September 2024 [12]. Anything happen just over 3 days ago? SilverLocust💬02:38, 5 September 2024 (UTC)
Though the reason why the expensive parser function limit was hit is simple enough. There are >500 redirects currently nominated, and therefore >500 instances of
This happened to us a few years ago at TFD when we embarked on a project to delete a few thousand unused and redundant templates. We had to slow down our nominations and list some of them on subpages. – Jonesey95 (talk) 05:02, 5 September 2024 (UTC)
The inexpensive alternatives are (1) a non-redirecting link that doesn't turn red after the RfD is closed as "delete" (or it's otherwise deleted), or (2) a normal wikilink that doesn't prevent redirection once the RfD is closed as "keep" (or the RfD banner is removed). SilverLocust💬07:15, 5 September 2024 (UTC)
Unless {{No redirect}} gets updated in a way that prevents expensive parser calls, I think either Option 2 or weak Option 3 is the winner there. The redirection should be prevented when the discussion is in progress due to the substitution of {{Redirect for discussion}} on the nominated redirect(s), and the option also allows the link to be red on the RfD if the redirect ends up being deleted. I can see a reason to have both links though, so my "weak option 3", but I don't see that option incredibly user-friendly as option 2. Steel1943 (talk) 19:46, 6 September 2024 (UTC)
As my account has now been "blocked" - I began to ponder, peacefully - if Wikipedia has a forum of experts who deliberate as a technical team to "block or not" or is it an individual who decides and activates a "block" on a fellow wikipedian?
I will patiently await a response or redirect to an article addressing my concerns. ZAWADI NPC (talk) 07:57, 6 September 2024 (UTC)
You were advertising on your page. Advertising is not allowed on Wikipedia, not even on your page. You don't own that page – it is only there to show people what kind of Wikipedia editor you are, not anything about your business. You may say something about hobbies or interests that you don't get money from, for example if you take great photographs and put them on Wikipedia (for free of course), then you can say so. TooManyFingers (talk) 19:23, 7 September 2024 (UTC)
Works for me. I null-edited the Infobox template. Editing the /doc template should, in a perfect world, immediately provide a null edit to the single page that transcludes it, but it rarely does so. – Jonesey95 (talk) 22:25, 7 September 2024 (UTC)
I was able to reproduce earlier in Firefox up to date, but no longer. Maybe indeed it was a question of needing a null edit. Izno (talk) 22:39, 7 September 2024 (UTC)
Current date templates break after entering source editor
@Roastedbeanz1: Your post could refer to different situations. Describe what you did from the start, what you expected and what happened instead. Save and link an edit where it happened. If you tried to add templates using source code like {{...}}} in VisualEditor then it's not supposed to work. VisualEditor has its own way of adding templates. See Help:VisualEditor#Editing templates. PrimeHunter (talk) 09:20, 8 September 2024 (UTC)
Auto-expand "Learn more about this page" on navigation to anchor
This is with reference to the trouble a user reported at Talk:Turkey#Extended-confirmed-protected edit request on 12 August 2024 and similar reports I've seen elsewhere. In mobile view, the tags at the top of a talk page are hidden under an expandable link reading "Learn more about this page". These tags may include, among other things, a FAQ tag. When, in a discussion on the page, we want to route an inquiring editor to the FAQ (such as to Talk:Turkey#FAQ), we can't do so for a mobile user because the link doesn't work and the user, even if they scroll to the top (which is now the second thing they've tried in their attempt to see the referenced material), don't see the FAQ and don't see the third thing, clicking "Learn more about this page" that they'd have to do to get there, or perhaps at that point they've already given up.
Is it possible through some feat of CSS and/or Javascript wizardry to cause the top material to expand automatically upon navigation to an anchor that's within it? Largoplazo (talk) 17:31, 8 September 2024 (UTC)
No search box for default skin
The search box at the top of the main page en.wikipedia.org is absent on the default skin, at least on certain browsers. There is an empty area where it would belong, but there's nothing visible or clickable there. This happens at least on some versions of Chrome. The default skin on mobile is still working fine. On desktop, switching skins fixes the problem. Could this be dark mode related? TooManyFingers (talk) 16:39, 7 September 2024 (UTC)
I found my problem.
1. Clicking the magnifying glass icon is now required, to use the search box.
Clicking the icon should be required only at smaller resolutions. But it should still be visible, so something there is weird. Izno (talk) 18:39, 7 September 2024 (UTC)
The problem I'm having is actually on wikiconference.org, not here, but I'm asking this here because this is where all the really smart people hang out :-)
I'm trying to generate some custom CSS for https://wikiconference.org/wiki/2024/Schedule which will let me highlight the talks I want to go to. this works, but only highlights the talk title. this one highlights every table cell (as expected). this one does exactly what I want (i.e. highlights the table cell containing the desired title), but when I go to save it, I get an error message "The document contains errors. Are you sure you want to save?" and "Error: Expected RPAREN at line 1, col 9". Ignoring the error message and clicking "OK" seems to work fine.
:has() was first-implemented in 2022 by Safari, then Chromium, then late 2023 by Firefox (implementing it was non-trivial for performance reasons), and I think went through a few name changes between 2018 and 2022. I am not surprised that the editor doesn't know it. Izno (talk) 16:41, 9 September 2024 (UTC)
Basically, enabling "Make headers of tables display as long as the table is in view" in Special:Preferences Gadgets results in the first table data row in templated tables being hidden by the table header rows shifted down. See Phabricator ticket for example and screenshots. ~Anachronist (talk) 14:19, 9 September 2024 (UTC)
Interestingly, it displays properly in Chrome if my window is about half the width of the screen, or if I turn on Developer Tools so that the display area is about half the width of the screen. --SarekOfVulcan (talk)14:28, 9 September 2024 (UTC)
Using Firefox and Dark Reader with Light Mode on, the icons are the same hue as the background and are not visible.
Fix by using Wikipedia's new Dark Mode? Not so fast. The background is too dark and the text is too bright. My eyes hurt when looking at it, and they don't hurt when using Dark Reader. This issue has already been raised by multiple users,[13] and will no doubt be solved in a timely fashion. But until then it would be nice to hit the undo button on whatever happened this week to the icons.
You are running into Apple's browser's inflation algorithm which is adjusting your font size to what it thinks is the preferred minimum font size because they consider the current font-size too small for the current page and your preferences. It's best to set your preferred font size locally on your device so it doesn't change again.
You can alter this by changing your font size on your device or if you have an account applying text-size-adjust in your user CSS.
@Jdlrobson: thanks for responding. I've tried something like this already, by having JavaScript revert the viewport back to width=100 (reverting the font size back to normal). What I don't understand is why this change was applied to legacy Vector, instead of just the new Vector. ‑‑Neveselbert (talk·contribs·email) 18:59, 10 September 2024 (UTC)
"Missing in" added to language selector with delay, disrupting the UI
Whenever I click on the language selector, it shows not only languages in which the article is available, but also suggestions of new languages to translate it in. (Which are never useful to me, but that is beside the point.)
The problem is that this suggestion appears with a delay of a second or so. See screencast:
Typically, I move my mouse cursor to the language name that I want to select, then just before I have the time to click, this suggestion appears and moves the target, so I end up clicking on the wrong languages.
When a bot edits a watched page or file, notification emails for subsequent human edits stop being sent. Notifications only resume once the page is manually viewed or the entire watchlist is marked as read. Has anyone not had this problem? ‑‑Neveselbert (talk·contribs·email) 19:11, 10 September 2024 (UTC)
I'm not sure if this is the right place, but why are navboxes not visible in mainspace articles in mobile view (unless rotated sideways)? They are visible in drafts. Kailash29792(talk)01:38, 11 September 2024 (UTC)
I have been having this issue for a while now and would like some help solving it. I use Advanced Mode as a mobile user. Occasionally, going to some pages in the Wikipedia or User namespaces will show me the non-Advanced Mode UI. Going to another page typically fixes this, and going into Settings shows that Advanced Mode is still turned on. This seems to happen most often when clicking a link from one Wikipedia namespace page to another page in that namespace, but will sometimes also happen in other circumstances. There is no visible pattern to when it happens. Does anyone know why this happens or how it can be fixed? Thanks, QuicoleJR (talk) 14:42, 6 September 2024 (UTC)
@QuicoleJR thank you, was clarifying if you were using the browser or the Wikipedia App. For your browser, assuming you are using Safari? Are you using the current version of Safari? — xaosfluxTalk14:55, 6 September 2024 (UTC)
Actually, no, I do not use Safari. I use the Google app (not Google Chrome, Google itself). I am using the current version of Google AFAICT. QuicoleJR (talk) 15:01, 6 September 2024 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Feature news
Starting this week, the standard syntax highlighter will receive new colors that make them compatible in dark mode. This is the first of many changes to come as part of a major upgrade to syntax highlighting. You can learn more about what's to come on the help page. [14][15]
Editors of wikis using Wikidata will now be notified of only relevant Wikidata changes in their watchlist. This is because the Lua functions entity:getSitelink() and mw.wikibase.getSitelink(qid) will have their logic unified for tracking different aspects of sitelinks to reduce junk notifications from inconsistent sitelinks tracking. [16]
Project updates
Users of all Wikis will have access to Wikimedia sites as read-only for a few minutes on September 25, starting at 15:00 UTC. This is a planned datacenter switchover for maintenance purposes. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [17]
Contributors of 11 Wikipedias, including English will have a new MOS namespace added to their Wikipedias. This improvement ensures that links beginning with MOS: (usually shortcuts to the Manual of Style) are not broken by Mooré Wikipedia (language code mos). [18]
Deployment of the MOS namespace on English Wikipedia is expected to happen tomorrow. I'll post a list of titles that need to be cleaned up after it happens; expected the bare [[MOS:]] and [[MoS:]] etc to break; please replace these with WP:MOS. C. Scott Ananian (WMF) (talk) 14:52, 11 September 2024 (UTC)
How to mark Minor Edit on Source Editor of Mobile website
I want to mark some of my edit as Minor Edit, but unable to do so with source editor. only Visual Editor provide interface to do that but i mostly work with source editor. how to mark any edit as minor edit on source editor of mobile website.
I noticed that my userpage was in Category:Pages with image sizes containing extra px. As it turned out, this was because I had specified |widths=80px. Removing the px solved it. This appears to be a WP:PXPX issue.
Checking a random sample of a dozen pages of the currently 8k+ in the category, I found that, in all cases, the member pages had the exact same issue with |widths= and/or |heights= specifications. Paradoctor (talk) 10:25, 8 September 2024 (UTC)
This is phab:T374311. I think it has always been suggested to include px in gallery sizes but now it adds the new tracking category. I think the gallery tag or tracking code should be modifed to allow one px in gallery wikitext without triggering the category, rather than mass-removing old px from all wikis to avoid the category. The suggestion to include px was removed from mw:Gallery examples yesterday and today.[19]PrimeHunter (talk) 12:49, 8 September 2024 (UTC)
This category appears to be broken at this time (false positives on properly configured gallery tags, per long-standing documentation at mediawiki.org), and possibly not needed at all, since Linter started detecting pxpx errors in 2023. I have commented at two related Phab tasks. – Jonesey95 (talk) 00:48, 10 September 2024 (UTC)
I don't see any pxpx in there. I agree that any hardcoded px should go away and live in the "gallery" declaration. That might allow us to use other units like em with code like "widths=10" being ambiguous. – Jonesey95 (talk) 01:31, 11 September 2024 (UTC)
I noticed some recent gallery's in articles that have this heading: <gallery mode=packed heights=250px>. The result is such a gallery having very big images, not the specified 250px but 469px high. I found the 469px by making a screenshot of the page (using Edge as browser, with zoom 100%), followed by cropping is to contain one image only. For an example see Wat Ket Karam. FredTC (talk) 11:14, 10 September 2024 (UTC)
The thumbnails are shown too big, because the parameter is not "heights" but "height". "<gallery mode=packed height=250px>" works fine.--Snævar (talk) 22:30, 10 September 2024 (UTC)
No, "heights" is correct. "height" is ignored as an unknown parameter and you get a default size. I don't know the precise algorithm when heights is used but it looks like the browser may calculate how many images will fit in a row with the current window width, and then enlarges the images so the whole window width is used, except it's limited how much it will enlarge an image. And MediaWiki apparently offers a larger image file than requested with the heights parameter so the browser has a good image to work with if enlargement is needed by the algorithm. PrimeHunter (talk) 00:01, 11 September 2024 (UTC)
Then this text:
heights= Image heights in pixels (has no effect if mode is set to slideshow)
Cite links are broken when VisualEditor is rendered in Parsoid
An odd bug that for some reason only affects, ironically enough, the article VisualEditor, which is why Parsoid began in the first place.
For some reason, all citation links, which should normally cause the query fragment of the citation ID to be used as a hyperlink, for example #cite-note_24 in the Technical section, instead get #Technical, the name of a subsection, prepended to them (so something like #Technical#cite-note_24) This naturally is an invalid ID for any element on the page, and thus citations aren't able to send you to where they're stored. Despite the name, this bug appears to affect every citation on the page, as well as the caret links back.
A quick search for another article with a level 3 header as Technical was, Oura Health, did not provoke this bug.
Something of note(maybe): The previous revision (permalink) of the VisualEditor article with Parsoid did not have broken anchors. I don't see anything in Special:Diff/1245017847 that could have caused it, though it is an edit to the #Technical subsection, hm. – 2804:F1...EE:9927 (talk) 20:15, 11 September 2024 (UTC)
...How did I forget about Special:Purge? Such a simple thing to fix a bizarre (?) bug. But yeah, the reason why I brought up Oura Health was that was my Special:Random-found "control group" article, to try to understand the nature of the bug. ("as Technical was" was meant to be understood in the sense that both articles had a level 3 header, not that Oura Health literally had a "Technical" subsection. But yeah, I wonder if/how this should be reported, given that the purge got rid of it. Regards, User:TheDragonFire300. (Contact me | Contributions). 23:22, 11 September 2024 (UTC)
What's the best fix for section titles containing ‹math› code?
I've come across some articles like List of repunit primes that have section titles like Bases such that is prime for prime which appear in the table of contents sidebar as Bases ?'"`UNIQ--postMath-00000001-QINU`"'? such that ?'"`UNIQ--postMath-00000002-QINU`"'? is prime for prime ?'"`UNIQ--postMath-00000003-QINU`"'. I presume this is another issue related to strip markers, but I'm not sure what the correct fix is. Should the section titles just be reworded and the <math> tags stripped out? Or is there a way to keep the math markup in the section titles without breaking the table of contents? 28bytes (talk) 22:13, 11 September 2024 (UTC)
I have "fixed" a few of these in the past—not really a fix because the math markup often gives a far better result in section headings. A bluesky solution might be for some new wikitext to define the heading for the contents, although that would give ugly wikitext and another hassle for visual editor developers. See this search to find more. Johnuniq (talk) 03:24, 12 September 2024 (UTC)
The request is to fix wikilinks which only say [[MOS:]] (or other capitalizations) without anything after the colon. Those links will become broken like [[Wikipedia:]] which produces [[Wikipedia:]]. It can be fixed by replacing the links with [[WP:MOS]] which produces WP:MOS. A linksto search currently finds 4908 links to [[MOS:]] so it sounds like a job for a bot or patient AWB users. PrimeHunter (talk) 15:43, 11 September 2024 (UTC)
It’s still many, many pages due to that template being substituted in every GA review. So PrimeHunter’s link is better (since it captures most of the cases which are boilerplate [[MoS:|…]], and your link doesn’t). stjn16:40, 11 September 2024 (UTC)
I have just done it. I have skipped user talk pages and just a handful of sandbox pages, for which a bot may be better to avoid OBODs.
I find it telling that of the 500 some odd links, the vast majority were added because of the one template being substed or transcluded. I think maybe only some 100 uses were actual natural links, and those across the time-space of 20 years... well, I wouldn't support the work of that task. There are better edge cases to support. Izno (talk) 17:51, 11 September 2024 (UTC)
I just did it after cscott made it obvious what the impact of many of these links was (adding an iw link to mos wiki and vanishing the original link in the process). Izno (talk) 15:32, 12 September 2024 (UTC)
Script just finished running. The list of affected titles is at T363538#10141129. Most of these look fairly harmless, eg if MOS:HEAD already exists, then the existing MoS:HEAD is (a) a conflict, and so gets moved to Broken/MOS:HEAD but (b) is also unnecessary, because the namespace is case-insensitive so existing links to MoS:HEAD "just work". So the Broken/ page can be safely deleted. C. Scott Ananian (WMF) (talk) 14:47, 12 September 2024 (UTC)
Template:Linux layers is working fine in light mode, but in dark mode, the <code>...</code> blocks (with text like "fopen") are unreadable dark gray text on dark gray background. It looks like that's happening from this CSS block:
Firefox is telling me it's the last item in the comma-separated list which is active. I think this might be coming from the built-in skin CSS? This is a complicated case because the surrounding background colors are pastel in both light and dark modes, but the background of the code tag itself is white in light mode and dark gray in dark mode. It would require careful testing if this is in fact a skin problem. -- Beland (talk) 03:37, 11 September 2024 (UTC)
Is this related to all HTML tags (that used to appear as green text in syntax highlighter) are now indistinguishable from plaintext when viewed in dark mode? Started yesterday on Wikivoyage, and today here on en.wiki. Zinnober9 (talk) 22:06, 12 September 2024 (UTC)
Until today, the "New pages" list were bright yellow highlight if no one had looked at them. It was very helpful in spotting new articles that needed editing. As of about an hour ago, that bright yellow went away and has been replaced by a very blah and light flesh colored background for the new pages. The new color, if you can even call it a color, only makes it more hard to scroll for entries. — Maile (talk) 00:25, 13 September 2024 (UTC)
Just copy-paste the line to User:Maile66/common.css and ignore the warning about li.not-patrolled being overqualified. It's a yellow warning, not a red error. I added li to override the existing color declaration for not-patrolled. PrimeHunter (talk) 15:27, 13 September 2024 (UTC)
I feel like specifying formulas inline could be susceptible to subtle vandalism which would be undesirable. I'm also seeing mentions of eval, can you comment on how this calculations are being done ? (I'll note evaling user-generated content on Wikimedia sites should probably be a no-go from a security POV). Sohom (talk) 16:57, 5 September 2024 (UTC)
Everything on Wikipedia is susceptible to vandalism; it doesn't mean we stop mentioning people's birth dates and other details which can be subtly fabricated. The calculators could be made templates which can be protected if necessary. Evalling is fine if inputs are sanitised. – SD0001 (talk) 17:10, 5 September 2024 (UTC)
@SD0001 Wrt to the first point, my thought process was that manipulating birthdays would be a lesser issue than manipulating a BMI calculator that could be potentially be used by people to self-diagnose metabolism disorders. Regarding the rest, on looking further at the code, I agree that security shouldn't be a issue for it's current version, however, it would be nice to document the method the script uses anyway (as a comment) to make sure future editors of the script are aware of this consideration. Sohom (talk) 19:33, 5 September 2024 (UTC)
The tl;dr is that the formulas are parsed using a simple Recursive descent parser into an AST type structure. The AST is evaluated by walking through the tree. In the tree there are OP nodes that represent an operation from a fixed set of valid operations implemented in javascript. A dependency graph structure is also created in order to refresh any widgets that depend on a value that was changed with loop detection. Bawolff (talk) 19:41, 5 September 2024 (UTC)
@Sohom Datta this would serve the user some javascript, execution is client-side via browser. The script code itself could only be modified by interface admins. The current script would always be viewable by anyone, and is currently available to see at this link. — xaosfluxTalk19:30, 5 September 2024 (UTC)
See my comment just above regarding this, I agree that is probably safe, but it would make sense to document the security considerations in the code for future interface admins/script editors. Sohom (talk) 19:36, 5 September 2024 (UTC)
Useful gadget, but it should be placed below the infobox rather than inside it, because it's somewhat unnoticeable when its placed inside the infobox. Vestrian24Bio (TALK) 14:42, 13 September 2024 (UTC)
Prior to larger development, a trigger category Category:Pages using gadget Calculator should be built. Additionally, related templates and documentation are needed. How to present the template when the gadget isn't running or javascript isn't running should be discussed. Finally, the non-technical consideration of article styling/usage consideration (such as what @Vestrian24Bio brought up above) should be discussed. — xaosfluxTalk15:14, 13 September 2024 (UTC)
Who controls the tooltips, popup, etc.? Is it the developers, or can we administrators edit some MediaWiki page that controls them? I just now logged out, and I was shown a brief popup with the following text:
"You are being logged out, please wait."
This has a clear comma splice, so it needs to have the comma replaced with a semicolon, but I'm not sure how to do it or whom to ask. The popup wasn't really a separate window; it looked more like a tooltip, but it appeared only after I clicked the link, so it's not really a tooltip. Nyttend (talk) 04:49, 13 September 2024 (UTC)
Accounts and passwords never expire. If you have a spam folder, maybe at your email provider, then try checking it. If you post the username (on this public page which already shows your IP address) then we can check whether the account exists and has an email address stored, but that's all. We cannot see what the email address is. If you didn't store one or cannot receive mail at it then you have to create new account. PrimeHunter (talk) 21:41, 13 September 2024 (UTC)
Thank you, I've been checking my spam folders, but I'm not getting an email.
The account User:Emdub510 does exist and has set an email address but has chosen to not receive mails from other users. The account was created in 2006. Most users rarely or never use our email features so it's plausible you gave the email address in 2006 and never needed it before now. Maybe you changed email address? The account has made 119 edits (only 1 since 2011). That's low by Wikipedia standards. You can just create a new account. If you want you can write on the user page of the old and new account that you are the same user. PrimeHunter (talk) 23:28, 13 September 2024 (UTC)
Your best course of action might be to file a bug report in Phabricator about not receiving the password reset emails for your account. The developers can both look into that and offer any alternatives. Anomie⚔13:34, 14 September 2024 (UTC)
Problem with account creation in Germany
I'm unable to create an account, because I always get the message "Visitors to Wikipedia using your IP address have created 6 accounts in the last 24 hours..." It seems like something is broken. I asked about it a few days ago at the Help Desk: Wikipedia:Help desk/Archives/2024 September 10#Unable to create account - a few admins looked at it, but couldn't help.
My Mac computer has a dynamic IP on O2/Telefonica in Germany. It changes once a day usually, or if I power-cycle my router. I've tried about 20 different IP numbers, over the past week, and it's always the same. I've tried several different browsers, emptying my cache, and creating a fresh browser profile in Firefox. It's also happening on my phone. I've tried using my phone's browser on WiFi. Then I turned off WiFi, and used the phone's cellular data, which is also on O2/Telefonica, but mobile. I tried using the phone as a mobile hotspot for my computer. But it's always the same error message, no matter what I do.
It seems unlikely that every single address has been used to create multiple Wikipedia accounts in the past day. Like there would have to be some kind of bot net cycling through IP numbers and creating thousands of accounts. Otherwise, because the number doesn't change that often, it feels like something is malfunctioning, and that it's not my equipment. If so, it may be affecting a large number of people, since this is a major ISP and this address pool covers a large part of Germany, including Berlin. I understand I could try to use the "request an account" page, but I wanted to report this as possibly a bug. Any ideas, or someone else I should talk to? Thanks. 77.183.18.209 (talk) 15:17, 15 September 2024 (UTC)
Thanks, I understand I can request an account that way, but I prefer not to give my real e-mail address (even if it's not retained), and it says that I can't use a throw-away address. So it's a little inconvenient. But the main thing is that this seems like a bug that should be reported and fixed, if it's affecting more than just me. 77.183.18.209 (talk) 15:37, 15 September 2024 (UTC)
There may be a more legitimate reason as to why your IPv4 address hits the 6-account creation limit: your service provider may be using a CGNAT setup in which the same IPv4 address is potentially shared across hundreds of their subscribers. How to determine you are on CGNAT, check your modem/router WAN IP address, and see if it matches your public address (which you can check with a third party website such as https://whatismyipaddress.com/). If indeed it is a CGNAT setup, you can only registere through WP:ACC or access Wikipedia on another ISP that does not use CGNAT or see if you can force an IPv6-only connection on your current provider (not sure if this will work through). – robertsky (talk) 15:38, 15 September 2024 (UTC)
@Robertsky: Thanks for the info. I don't think that's the case though. If I log into my router's admin interface, the WAN address listed is the same as the public IP address reported by whatismyipaddress.com. The IPv6 number is blank in the router, and not listed on whatismyipaddress.com. But if I use my phone as a mobile hotspot, with cellular data (which I'm doing right now), I do get an IPv6 number. But I just tried again, and I still get the "more than 6 accounts" message. 2A02:3032:312:C23E:651B:88A4:497B:5E99 (talk) 16:01, 15 September 2024 (UTC)
Back on DSL again - according to o2 customer service CGNAT is not used on my DSL line. I also did a traceroute on my WAN IP, and there's only one hop. 77.183.18.209 (talk) 17:19, 15 September 2024 (UTC)
The Interface
About how text is displayed:
As for the Italic text feature in English, it is towards the right. But this happens even for the Arabic language, and this is considered a Wrong.
There is another matter, I see that the level of spacing between the lines along the article page is too far apart from each other.
@Mohmad Abdul sahib: I don't know Arabic but if I understand you correctly, you are saying that Wikipedia displays italic text slanted to the right for the Arabic script but we shouln't do that. Our software just places the html tag <i>...</i> around text to say it should be displayed in italics. Your browser makes the rendering you see on your screen. Arabic text: اَلْعَرَبِيَّةُ. Same text in italics: اَلْعَرَبِيَّةُ. I do see the italic version slanted to the right in Firefox. I Googled the issue and found that italics traditionally aren't used at all in Arabic but if fonts support italics for Arabic then they generally slant it to the right like the Latin script. Slanting Arabic italics to the left doesn't appear to be an option with normal fonts. Is your concern about the English or Arabic Wikipedia? If it's the Arabic then you will have to take it there. If it's English then please give an example page. Should we try to avoid using italics in Arabic text if slanting it to the left is not possible? PrimeHunter (talk) 20:16, 15 September 2024 (UTC)
@PrimeHunter. I meant that every language has a way of writing. For example, when you write in English, the direction of the text will be from left to right, but in the Arabic language, the way of writing is from right to left. What I mean is that in all interfaces, the display locations will differ, whether fonts, icons, options, and the like. I do not mean only the Arabic language, but rather all languages on Wikipedia. The text must be Italiced according to the way it is written.
You lost me when you started talking about icons, options and all languages. I thought this was something specific about how to slant italic text in the Arabic script. PrimeHunter (talk) 21:24, 15 September 2024 (UTC)
The issue should be irrelevant, as long as pages are complying with MOS:BADITALICS, which says Text in non-Latin scripts (such as Greek, Cyrillic or Chinese) should neither be italicized as non-English nor bolded. Italic markup around Arabic script should pretty much always be removed. – Jonesey95 (talk) 01:13, 16 September 2024 (UTC)
I tried enwiki-20240820-pages-articles.xml.bz2 and the latest enwiki dump but 7zip and bzip2 keep failing. I redownloaded it multiple times. I'm on Pop OS and there is plenty of disk space available of course.
I am using 7z x enwiki-20240820-pages-articles.xml.bz2 and
bzip2 -d enwiki-20240820-pages-articles.xml.bz2 to extract.
Thanks. So far I figured out that the problem is in all tools that use libbzip2 under the hood (I think 7zip and pbzip2 and bzip2). The problem is that the default block size is 900.000 bytes, and if you go over that you get:
pbzip2 -dkv enwiki-latest-pages-articles.xml.bz2
Parallel BZIP2 v1.1.13 [Dec 18, 2015]
By: Jeff Gilchrist [http://compression.ca]
Major contributions: Yavor Nikolov [http://javornikolov.wordpress.com]
Uses libbzip2 by Julian Seward
# CPUs: 20
Maximum Memory: 100 MB
Ignore Trailing Garbage: off
-------------------------------------------
File #: 1 of 1
Input Name: enwiki-latest-pages-articles.xml.bz2
Output Name: enwiki-latest-pages-articles.xml
BWT Block Size: 900k
Input Size: 22880311372 bytes
Decompressing data...
pbzip2: *ERROR: Could not write 900000 bytes to file [ret=-1]! Aborting...
pbzip2: *ERROR: system call failed with errno=[2: No such file or directory]!
pbzip2: *ERROR: system call failed with errno=[5: Input/output error]!
Terminator thread: premature exit requested - quitting...
Cleanup unfinished work [Outfile: enwiki-latest-pages-articles.xml]...
Deleting output file: enwiki-latest-pages-articles.xml, if it exists...
pbzip2: *INFO: Deletion of output file succeeded.
@TheDJ Yeah I wondered about that. To be honest I was so happy it finally worked that I didn't do any digging. The memory was limited to (the default) 100mb I think, despite the fact that there was ~64gb RAM available. Polygnotus (talk) 04:03, 16 September 2024 (UTC)
Position of pending changes lock
Could we revert to how the position of the "pending changes" lock looked before? Now it looks like this, with "Pending" wording next to it with a crossed out eye. The previous lock was a simple compact lock icon with a tick, did not include text or other additional features (like the crossed-out eye) and was less obtrusive and didn't draw as much attention. I'd like to restore the lock to its previous visual format whilst making sure users can still understand its meaning (that there are pending changes, which should already be handled by users pressing "Edit source" and the note coming up). Best, 750h+16:54, 15 September 2024 (UTC)
@750h+ Could you be specific which page this is; I don't see it in ordinary pages.
I see what you mean, but the check does shows information about the page review status when hovering over it. Vestrian24Bio (TALK) 03:37, 16 September 2024 (UTC)
I still see no point of it. It's obtrusive (the previous layout was much better) and i feel that this could be fixed by allowing the user to hover it and see the review status. 750h+03:39, 16 September 2024 (UTC)
I also dislike the change. It's too "busy", the eye icon seems out of place (there's already an equally awful glasses icon which has a different meaning), and it's not visually pleasant. Daniel Quinlan (talk) 04:29, 16 September 2024 (UTC)
I recently ran into a problem with Template:Infobox aircraft at NAL Hansa in which a long "designer" parameter input resulted in an excessively wide infobox (see this diff). I was able to temporarily fix the issue on the article, but I would like to prevent similar issues by constraining the infobox size to a fixed maximum value. With how much experience I have with templates, I should know how to do this, but I don't. Does anyone know how to do this? - ZLEAT\C19:43, 16 September 2024 (UTC)
@ZLEA: It happened because Prarambh20 used {{Nowrap}} on the designer parameter in [24]. I don't see a good reason for nowrap and suggest to just remove it. Prarambh20 hasn't edited since June 2023. nowrap was also used on two other parameters but those parameters have been removed. PrimeHunter (talk) 20:02, 16 September 2024 (UTC)
Just realized that this doesn't fully answer your question. I think replacing width with max-width might have the effect you want. jlwoodwa (talk) 20:06, 16 September 2024 (UTC)
An IP editor came to my user talk, and said he was unable to edit an article talk page. So, I logged out, and tried editing article talk pages, but was also unable. What’s up? Anythingyouwant (talk) 05:04, 12 September 2024 (UTC)
Seeing your user talk page, the person who asked you is not an IP editor. Their described problem also happened after clicking "Add topic", which you managed to do successfully (you just hit an edit filter that prevents creating very short talk page topics as an IP or new user, the user in your user talk page did not hit that filter though).
Again, you are hitting an edit filter, specifically Special:AbuseFilter/1245, which, if I read the code correctly, prevents users who are not autoconfirmed or confirmed (which includes all IPs) from adding new talk page topics that have a title that is 2 words or less and a content that is 2 words or less (and less than 300 characters total).
I had originally tried to add the topic to Talk:Hunter_Biden_laptop_controversy without logging in. When it failed I created User:Swan2024, but I still have the same problem. I just tried again while logged in and it still fails the same way (moving slanted lines over the text for a few seconds, then gives up). I don't see any warning/error messages. I checked Special:AbuseLog and do not see any entries for me. Any other ideas? Swan2024 (talk) 00:11, 13 September 2024 (UTC)
@Swan2024: If you are trying to add external links then place them inside <nowiki>...</nowiki> in source mode to deactivate them. The add topic feature doesn't currently work with external links for users who are not autoconfirmed which requires four days and ten edits. PrimeHunter (talk) 18:28, 13 September 2024 (UTC)
Huh? Is this mentioned anywhere? That does seem to be it (can reproduce with a link to Google)...
There was an issue with the new topic tool which was stopping any save error messages from being shown, which includes captchas. This is being fixed, and should be back to working for everyone by Thursday (or earlier if we decided to go to special efforts to backport it) DLynch (WMF) (talk) 00:42, 17 September 2024 (UTC)
Losing edits after logging in
I was editing an article (in the old, non-visual editing format, in case it matters) and upon clicking Submit, a notice came up encouraging me to log in before posting the edit. I clicked the notice's link to the Log In page, filled in my user info, successfully logged in, and was brought back to the same Edit page I was on... only to notice, to my horror, that all my changes did NOT get saved and were completely gone! This is a horrific thing in terms of user friendliness! No one should be punished for following Wikipedia's own suggestion. Thankfully my edits were only 5 minutes of work so I was able to reconstruct it, but what if it had taken, say, hours? I would definitely be so disconcerted that I would probably never edit Wikipedia again out of sheer trauma. — Preceding unsigned comment added by Ericobnn (talk • contribs) 23:28, 16 September 2024 (UTC)
Hi @Ericobnn, sorry that happened to you. Your browser should have displayed a warning message that you will lose unsaved changes when clicking the "log in" link. Anyway, there is a fairly new Edit Recovery feature, which would have helped in this scenario – you can enable it under "Editing" in your preferences, and hopefully it will be enabled by default soon. The visual editing mode has a similar feature enabled by default already. Matma Rextalk05:24, 17 September 2024 (UTC)
Undo Function on Mobile
I was reading The Eustace Diamonds and noticed an addition that needed to be removed because it wasn't constructive. I was reading on mobile and realised I couldn't use the undo function via the page history on mobile. Is this deliberate? Red Fiona (talk) 20:14, 15 September 2024 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Improvements and Maintenance
Editors interested in templates can help by reading the latest Wishlist focus area, Template recall and discovery, and share your feedback on the talkpage. This input helps the Community Tech team to decide the right technical approach to build. Everyone is also encouraged to continue adding new wishes.
The new automated Special:NamespaceInfo page helps editors understand which namespaces exist on each wiki, and some details about how they are configured. Thanks to DannyS712 for these improvements. [26]
References Check is a feature that encourages editors to add a citation when they add a new paragraph to a Wikipedia article. For a short time, the corresponding tag "Edit Check (references) activated" was erroneously being applied to some edits outside of the main namespace. This has been fixed. [27]
It is now possible for a wiki community to change the order in which a page’s categories are displayed on their wiki. By default, categories are displayed in the order they appear in the wikitext. Now, wikis with a consensus to do so can request a configuration change to display them in alphabetical order. [28]
Tool authors can now access ToolsDB's public databases from both Quarry and Superset. Those databases have always been accessible to every Toolforge user, but they are now more broadly accessible, as Quarry can be accessed by anyone with a Wikimedia account. In addition, Quarry's internal database can now be queried from Quarry itself. This database contains information about all queries that are being run and starred by users in Quarry. This information was already public through the web interface, but you can now query it using SQL. You can read more about that, and 20 other community-submitted tasks that were resolved last week.
Any pages or tools that still use the very old CSS classes mw-message-box need to be updated. These old classes will be removed next week or soon afterwards. Editors can use a global-search to determine what needs to be changed. It is possible to use the newer cdx-message group of classes as a replacement (see the relevant Codex documentation, and an example update), but using locally defined onwiki classes would be best. [29]
Technical project updates
Next week, all Wikimedia wikis will be read-only for a few minutes. This will start on September 25 at 15:00 UTC. This is a planned datacenter switchover for maintenance purposes. This maintenance process also targets other services. The previous switchover took 3 minutes, and the Site Reliability Engineering teams use many tools to make sure that this essential maintenance work happens as quickly as possible. [30]
Tech in depth
The latest monthly MediaWiki Product Insights newsletter is available. This edition includes details about: research about hook handlers to help simplify development, research about performance improvements, work to improve the REST API for end-users, and more.
To learn more about the technology behind the Wikimedia projects, you can now watch sessions from the technology track at Wikimania 2024 on Commons. This week, check out:
Hackathon Showcase (45 mins) - 19 short presentations by some of the Hackathon participants, describing some of the projects they worked on, such as automated testing of maintenance scripts, a video-cutting command line tool, and interface improvements for various tools. There are more details and links available in the Phabricator task.
Co-Creating a Sustainable Future for the Toolforge Ecosystem (40 mins) - a roundtable discussion for tool-maintainers, users, and supporters of Toolforge about how to make the platform sustainable and how to evaluate the tools available there.
@Izno As I'm reading it, this change only removes support for mw-message-box from the Vector 2022 skin, and won't actually remove the class from system messages, so it wouldn't affect scripts like mine that are using it as a selector. Scripts that create message boxes should use both the mw-message-box and codex classes to maintain compatibility with Vector 2010 and other older skins. --Ahecht (TALK PAGE)15:17, 17 September 2024 (UTC)
Keep bots from archiving unanswered edit requests?
@Sumanuil: Archiving bots don't care if a request is answered or not, and generally speaking, have no way of knowing. They work on a basis of time elapsed since the last post to that thread. However, ClueBot III has a feature where it will also archive threads that are explicitly marked with some tag, such as {{done}} even if the archiving time limit has not been reached. I see that this has been set up at Wikipedia:WikiProject U.S. Roads/Shields task force/Requests - it's the |archivenow= parameter - but that does not prevent the |age= parameter from also being taken into account. The thing to do is set |age= to a very high value - a minimum of 4368, which is six months.
@Wbm1058 All these cite Grove templates include a copy of {{Grove templates}} in their documentation page to link between each other. {{Grove templates}} does not have it's documentation template in noinclude tags (it was deleted by accident in this edit [32]), so you end up with a documentation template in a documentation template. 86.23.109.101 (talk) 23:07, 17 September 2024 (UTC)
Oof, horrible. This is really a WP:MOS question rather than a VPT question, but I killed that formatting with fire. The all-caps months can probably be fixed as well. – Jonesey95 (talk) 11:00, 17 September 2024 (UTC)
With fire? That was a stronger response than I was expecting. However, if you check the page history, you will see that I actually went a bit further but was reverted. I was going to post in the project talk page to discuss an overall fix – there are lots[clarification needed] of other film list articles that use that pattern — GhostInTheMachinetalk to me11:40, 17 September 2024 (UTC)
Issue is not with just one article as some people jumped in and started editing after the start of this discussion😂. Same format is there in British films and Australian films also. The fundamental question is regarding the template used for film lists (year-wise). Make or improve the template and deploy to all film lists and let us follow it. Anish Viswa 04:54, 18 September 2024 (UTC)
It is horrifying to see that this is not just a one-off problem. Thanks for the link. I opened a discussion on the article's talk page. – Jonesey95 (talk) 14:10, 18 September 2024 (UTC)
Something to do with templates that produce no output. Perhaps phab:T369520? The cure, apparently, is to add a leading <nowiki /> tag. Why? Don't know.
If a template has no output then a call of the template placed on its own line becomes a blank line, causing whitespace. If the template returns a nowiki then MediaWiki doesn't treat it as a blank line. PrimeHunter (talk) 00:13, 19 September 2024 (UTC)
Not sure where else to properly propose or showcase this, but I did a refactor of the Unicode block template design, introducing various BCP bells and whistles—namely dark mode support via TemplateStyles (Template:Unicode chart/styles minimal.css). Sadly, I can't use <tfoot>. Compare {{Unicode chart CJK Radicals Supplement}}
@Gonnym suggested the bare EL be converted into a reference. I think I agree with that, but I didn't want to unilaterally change everything at once. It's a pretty dated design though, while several editors have tried to redesign it but haven't completed it. So, I guess I wanted to triage it and do everything right while keeping the manual work of fixing every block manageable. Remsense ‥ 论15:37, 11 September 2024 (UTC)
A nitpick: I don't love the use of two different fonts and font sizes for the column and row headers, especially since both appear to be different from the base page font. Is there a reason for these fonts to be different from the base page font? See MOS:FONTFAMILY for a guideline. – Jonesey95 (talk) 17:09, 11 September 2024 (UTC)
Thanks for the nitpick, of course! I wouldn't do it purely for decoration per guidelines and good sense; I could easily lose one of the font sizes which was just mirroring the original, but the monospace is due to it being a computer-based code point, I guess? Now that I'm interrogating that again, it's a rather weak reason to insist on it, I think I can 86 that too. Remsense ‥ 论17:13, 11 September 2024 (UTC)
I do think the table footer is a bit visually distracting at 1rem, especially if the string appears several times on a page corresponding to several blocks. What do you think? Remsense ‥ 论17:19, 11 September 2024 (UTC)
Definitely restore the normal-sized and fixed-pitch row and column headers (you might try making *all* the characters normal-sized). Try to make the cells perfectly square and as small as possible, they seem to not be square and are bigger than before. I would just put the text "Unicode 16.0" in the header with a ref leading to the PDF, and also there is no need to tell them that gray cells are unassigned, so both footnotes are removed. Spitzak (talk) 18:22, 11 September 2024 (UTC)
I'm not sure about making square cells—which would be easy to do—of course we inspect isolated glyphs in an ideal square, but I think this becomes significantly harder to read as a table that way. Though, I realize I've picked a CJK block to test this with, maybe that's different with a graphetically different script so square cells would be best.Remsense ‥ 论18:26, 11 September 2024 (UTC)
Hmm no, I'm full of it and square cells is obviously the move. I've allowed the headers to be bolded like in other tables instead, and I think that's good. Trying to step away so people can analyze for now. Remsense ‥ 论18:35, 11 September 2024 (UTC)
@Remsense: You can't use tfoot for the same reason that thead and tbody (also a, img and a bunch of others) can't be used - none of these are whitelisted in MediaWiki. --Redrose64 🌹 (talk) 20:45, 11 September 2024 (UTC)
I support the rewrite, especially on accessibility grounds, but nounderlines class should probably be removed: does it even serve a purpose here? (If it even has one at al.) stjn15:09, 12 September 2024 (UTC)
Seems like a pretty bad relic of a different time. I get the case for why someone though this might be a good idea, but removing underlines is also just removing pretty much the only way you can tell a link from a non-link apart in Wikipedia, so moving styles like that to TemplateStyles (where they target specific things) seems much better. stjn19:52, 12 September 2024 (UTC)
Yes, hence why it's in the TemplateStyles section of the page. The problem is that none of the classes of interest really go with specific templates, or are additionally employed in the "table" use case even when they do have a specific template in mind. So I haven't spent a ton of time trying to fix this one. Izno (talk) 20:11, 12 September 2024 (UTC)
Looking better but can you please restore the cell size to what it was in the original? We seem to be suffering some bloat, it is even larger than before. In addition the cell sizes should match the inline tables being used for 8-bit character sets, which were designed to match the original.
Though it was not in the original, making the row/col headers be fixed-pitch (as well as bold) would help for recognizing Hex values.
I still think the footer can be removed in the majority of cases. Put "Unicode 16.0" and the PDF link into the title, and just remove the "gray indicates non-assigned" as this is well known. Spitzak (talk) 17:46, 12 September 2024 (UTC)
I've reduced the effective padding, that looks better. I think I would like to maintain the table caption being used exclusively for the name of the block. I am also a hair skeptical that the meaning of gray squares is adequately intuitive to many readers who might be learning about Unicode or any related concept for the very first time, and they might not even really know that letters are assigned as such. That is to say, I think the note plausibly should remain. Remsense ‥ 论17:56, 12 September 2024 (UTC)
I found that fixed sized boxes with a very small padding is the way to get smaller boxes. They are still too large.
That's what I've done. Are you sure they're still too large? This is the worst case scenario for readability I think, with rather complex and diverse, square-filling glyphs. I worry if I reduce the spacing any more it will become more difficult to discern one glyph from another at a glance. Remsense ‥ 论18:18, 12 September 2024 (UTC)
Of course, then I actually try it again and decide it's fine after staring at it for a few seconds. Design is hard. Remsense ‥ 论18:20, 12 September 2024 (UTC)
Maybe just add the PDF as a ref to the title, with no unicode version text. The Unicode version is part of the title of the reference anyway.
Yes they are still too large, as they are larger than the original. Copy however the original version set the box sizes. These glyphs should not be causing the boxes to get larger, that should not happen until the glyph literally does not fit in the box, with zero padding. Spitzak (talk) 18:19, 12 September 2024 (UTC)
I like the fact that you fixed the width of the row headers. Do you think you could try fixed pitch? I think that will help as usually U+AB12 is being shown in a fixed-pitch font. Spitzak (talk) 18:23, 12 September 2024 (UTC)
I am on the fence about this choice as well, but I am often tugged towards parsimony (i.e. only using one font) but I'll try it out again now. Remsense ‥ 论18:29, 12 September 2024 (UTC)
That's odd, there's no reason for that to be the case, they're both set to font-family: monospace. I'll change it though to what our templates do instead. Remsense ‥ 论18:02, 13 September 2024 (UTC)
Makes sense! I have no idea why they would be tagged that, as it's not the case that the text is writing several different languages! Not sure why I bothered copying it over. Remsense ‥ 论20:20, 13 September 2024 (UTC)
I'm concerned about making the table design slicker at the expense of conveigying information clearly. That said, User:Remsense asked for my feedback on the redesign...
I'm as adamant about the use of "nounderlines" as I was ten years ago. Yes, readers are used to the use of underlines on Latin letters but it gets very confusing with unfamiliar letters/symbols. The best example is Template:Unicode chart Mathematical Operators. I contend that the change is color of the linked symbol is sufficient to alert the reader of a link.
I would like a PDF symbol in the header of the chart to the official Unicode code chart. I don't think it's intuitive to follow a reference for "As of Unicode version 16.0" to find the chart. That just buries this incredibly useful information. If you want to condense the information, what about this for the heading: Early Dynastic Cuneiform as of Unicode version 16.0 or Early Dynastic Cuneiform as of Unicode version 16.0 (official chart)
Be sure to test that the new block layout works when multiple charts appear on the same page, like Mon–Burmese script.
I don't really care which font is used for the headings/column heading but it will need to be different than the fonts (if any) for the data cells themselves. For example, Template:Unicode chart Ahom. We don't want to use Noto Serif Ahom for the entire chart, just the data cells. Not sure if the new format makes this an issue or not.
Thank you very much, it's just what I was hoping for! Of course, the last thing I want to do is make anything less clear, but I need to do everything wrong first Remsense ‥ 论21:35, 13 September 2024 (UTC)
I'm going to judge the EL vs. reflist citation position as no consensus for the moment, meaning I'll try a version with the existing convention as well. Further thoughts on each?
Unicode 16.0[2] – grey areas indicate non-assigned code points.
I strongly prefer the EL with the PDF symbol because it's much more obvious there's a PDF chart available. Especially nice if it's a block I don't have fonts installed for. DRMcCreedy (talk) 14:48, 18 September 2024 (UTC)
I'm so used to the current format that this never occurred to me. I guess that pushes us towards a normal citation. That said, I'd like the citation chapter parm changed to "Code chart for xxx" (where xxx is the block name) and the page number parm removed (because of the maintenance issues with new releases). DRMcCreedy (talk) 16:02, 18 September 2024 (UTC)
I'm happy to make any future changes if consensus agrees to them or problems are indicated; for the moment, is everyone okay with me starting to implement this new design, possibly as a handful of metatemplates, that can replace the existing unicode block templates? Also, third option: just put the citation template itself in the bar?
That is probably the worst option. Just make it a citation, there is no reason to prefer an inline icon for the link in the footer. stjn16:58, 19 September 2024 (UTC)
I only worry that it'll cause heartburn for those working with the bespoke citation styles existing in maybe 2–10 articles ever, but whatever at this point. Remsense ‥ 论17:01, 19 September 2024 (UTC)
Yes I think it should be a plain old citation in the header. The header could look like this:
Hard no on using the full citation in the header. I think that is still an inline citation so if breaks the MOS. I'm fine with just a reference so long as the title is "Code chart for ..." or "Official Code Chart for ...". DRMcCreedy (talk) 21:44, 19 September 2024 (UTC)
I notice the page numbers are still on the reference. I'd like to reiterate that these are a maintenance issue and not useful to the reader because they will just pull up the PDF, not look up the page numbers is some hardcopy or omnibus PDF. DRMcCreedy (talk) 14:33, 20 September 2024 (UTC)
Not sure if this is just on my end, but when I open the template page, I get the message "The time allocated for running scripts has expired.". I've searched through the archives but I have no clue how to check the Lua runtime and don't even know if if it needs to be fixed or if this'll just go away, but just thought I'd make the pump aware. Sincerely, Dilettante20:20, 19 September 2024 (UTC)
@Dilettante, Kindlejim, Mathglot, Izno: Oops, my bad. I implemented an automatic version of {{Inflation/year}} that uses Lua, but it turns out mw.text.split() is incredibly slow. Replacing it with a home-grown splitting function made it 20x faster. I've fixed the Lua module and re-implemented it, and it's now working with all the above pages (except Pouakai Range, which appears to be an unrelated issue with {{Maplink}}). --Ahecht (TALK PAGE)00:06, 20 September 2024 (UTC)
Ahecht, Thanks. It sounds like something wildly beyond normal expectation, especially since your home-brew version was so much faster. I don't know Lua yet, but mw.text.split() looks like it might be some imported library routine defined externally somewhere. If that's close to right, would you mind commenting/filing a Phabricator ticket or whatever the right response is about that routine, wherever it happens to be? Mathglot (talk) 00:19, 20 September 2024 (UTC)
@Ahecht:, closed again; see this comment. Do you think you can create a new ticket for this? You are much more plugged in to what is going on here than I am, and I fear my explanation would not be complete or accurate. Thanks, Mathglot (talk) 11:19, 21 September 2024 (UTC)
@Mathglot I really don't know too much about the issue other than what is in that ticket, and I fear that a regression that occurred 3 years ago may be hard to track down. --Ahecht (TALK PAGE)22:58, 21 September 2024 (UTC)
"The time allocated for running scripts has expired"
In the process of doing some category cleanup today, I came across Albert Bridge, London, a page which looks fine at first, but about halfway down once you get to the "structural weaknesses" section, becomes absolutely swarmed with a constant profusion of blaring red "The time allocated for running scripts has expired" error messages every time there's supposed to be a footnote. The last time I saw something like this, it was because the affected page had recently been moved, so there was a conflict between its title and the title that was being expected by various templates, but that doesn't seem to be the case here as the page hasn't been moved at all. So could somebody take a look at this and figure out how to fix whatever's wrong? Thanks. Bearcat (talk) 20:47, 19 September 2024 (UTC)
It's about window width. It also happens in narrow desktop windows but not in wide mobile windows. The green background always stops right after the "show" link. The difference in narrow windows is that the show link moves to the left. I don't know why. PrimeHunter (talk) 11:59, 20 September 2024 (UTC)
I've eliminated your table content as a factor; that does not affect it. But the length of the title field in the collapse bar does. The first cot/cob below shows the same problem, but the second does not:
{{Cot|Version 1}}
|-
| {{lipspan|1}}
|}
{{Cot|Version 1 - same, but with a longer title field; there must be a clue here somewhere}}
|-
| {{lipspan|1}}
|}
The generated Html for the first one looks like this:
Generated Html for top example:
<div style="margin-left:0">
{| class="mw-collapsible mw-archivedtalk mw-collapsed " style="background: transparent; text-align: left; border: 1px solid Silver; margin: 0.2em auto auto; width:100%; clear: both; padding: 1px;"
|-
! style="background: #CCFFCC; font-size:87%; padding:0.2em 0.3em; text-align:center; " | <div style="font-size:115%;margin:0 4em">Version 1</div>
|-
| style="border: solid 1px Silver; padding: 0.6em; background: White;" |
|-
| Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
|}
Note that when expanded, the problem does not appear. Maybe this will help point the way to where to go next with this analysis. Mathglot (talk) 00:11, 21 September 2024 (UTC)
Here is a small example:
{| style="border: 1px solid"
|- style="background-color: cyan;"
| Test
|}
Test
In a narrow window, the table border is widened to the full width but the background color is not included in the widened part. Tested in Firefox in Vector 2022 and Vector legacy. PrimeHunter (talk) 09:34, 21 September 2024 (UTC)
Again the content length matters:
{| style="border: 1px solid"
|- style="background-color: azure;"
| testing whether that nation, or any nation so conceived and so dedicated, can long endure
|}
testing whether that nation, or any nation so conceived and so dedicated, can long endure
For a table, the display: property defaults to display:table; which would cause that max-width: 100%; declaration to be ignored, but this rule overrides it. --Redrose64 🌹 (talk) 13:44, 21 September 2024 (UTC)
It's an unknown table, so the table defaults kick in (to allow for scrolling, in case the thing is superwide). Those defaults do not take into that something has a colored background like that and by default, the background for that element will thus not be maximum width wide, but content wide. —TheDJ (talk • contribs) 00:53, 22 September 2024 (UTC)
Have you taken the step of grabbing the right edge of your browser window, and slowly dragged it left, until you see a jump in the background color of the title bar to half the width of the title bar (meaning the right half has white backgroundd) as the window shrinks to 1/3 or 1/5 of its former width? How is your explanation related to this behavior? And, what is an "unknown table"? Mathglot (talk) 01:21, 22 September 2024 (UTC)
This would effectively be fixed if someone took the time to convert {{collapse top}} and any bottom templates (collapse bot, possibly others) to use divs rather than tables. They will need to be point person on any issues that come up. I can support. (I just don't have it in me to do it by myself. :) Izno (talk) 16:27, 22 September 2024 (UTC)
Hi, I would like a dump for the following: All Featured articles, All featured lists, All good articles, and all Vital Articles (All levels). Preferrably in separate files for each of the requests. And also preferably in html, pdf, or a similar format. I don’t like the xml one due to it having the coding and unnecessary stuff included. Is this possible? I was told to come here after asking on Help Desk. Thanks, MrM MiniMikeRM (talk) 12:47, 19 September 2024 (UTC)
There may well be more items with this issue by now.
I have resolved a couple by looking at the Wayback Machine history, so it is possible. The community needs to decide how we deal with both the backlog and the issue going forward.
Is there an #if test I can do on some variable, or an #ifexist <file> to check if a user has their newcomer home page enabled? I wish to provide a link at H:YFA to the newcomer home page (Special:Homepage), but only if they have one. A magic word {{HOMEPAGE}} that returns non-empty would be nice, but anything that works is good.
Note: if you are an experienced user reading this, that Special link probably goes nowhere for you, as it did for me, until I enabled it in the bottom section at Preferences. If you've never seen the Homepage, it's interesting, and if you are a WP:Tea house aficionado, it may help you help others. Mathglot (talk) 19:27, 19 September 2024 (UTC)
Two points of context to know more about the user case you envision, @Mathglot:
Since August 2022, all newcomers have access to the homepage.
Some (more experienced) users opted-out the homepage in their preferences, but they know that.
Could we say these two points are a enough to consider that the number of newcomers who would have a "no access" message is low enough to add the link to H:YFA? Trizek_(WMF) (talk) 10:48, 20 September 2024 (UTC)
Trizek_(WMF}, thanks for this. You echo my musings about this, as I have been thinking about adding it anyway, and assumed that all new users have the page, and that at least some older users don't, either because like me, they predate the feature, or that other editors have opted out on the Preferences page (or maybe aged out automatically after X-hundred or-thousand edits or whatever). So, I was coming around to your view, and hearing these details cinches it; I will add the link. Thanks for jumping in.
P.S. You might consider adding a WP:DOPPELGANGER account for Trizek (WMF), which is how I automatically spelled your name while typing, to prevent any future mischief. Most WMF users use blank there, not underscore as I recall, so it's a familiar pattern. Thanks, Mathglot (talk) 17:46, 20 September 2024 (UTC)
Ha, sorry for the confusion regarding the underscore @Mathglot! It is the opposite effect I was looking for: I added it to my signature as a global setting for RTL languages. It is also for other users who miss the parenthesis: they are quite regularly pinging my volunteer account... ;) Trizek_(WMF) (talk) 12:32, 23 September 2024 (UTC)
New quirk, opening Wikipedia on Firefox (Chrome and Edge are fine)
Yesterday, I ran the McAfee "Tracker Remover". Normally, that's routine, and nothing odd happens, but I am wondering if my new quirk was triggered by McAfee . Normally I don't sign out when I leave Wikipedia for the day. But as of today, I'm having issues with Firefox
asking me to sign in to Wikipedia. I click without password, and it opens anyway. It's just odd that it asked me to do that. If I open on Chrome or Microsoft Edge instead, both take me right into the Wikipedia page I want without asking for a password. Feedback welcome on this, please. — Maile (talk) 20:31, 19 September 2024 (UTC)
I was asked to investigate a problem with {{convert}} at the Ukrainian Wikipedia. I have edited some pages there and am curious about the effect of a new user (me) editing a pending-changes protected page such as uk:Module:Convert/пісочниця (/sandbox). When I look at that page in a private window where I am not logged in, I can find "pername". I added that in the most recent edit which history shows as "pending review". Also, the pername change to the module is used at uk:User:Johnuniq/convert#pername (it shows dummy text "miPER" and "acrePER" in the output). In other words, an edit to the module which has not been reviewed still has an effect that is visible to all. This is not important—I'm just curious about WP:Pending changes. It appears that PC on a module does not achieve much other than flagging it as needing review? Johnuniq (talk) 02:58, 23 September 2024 (UTC)
I think templates work the way one would expect, I would guess Scribunto content model pages just don't... Maybe @Stjn knows. Izno (talk) 03:12, 23 September 2024 (UTC)
I just tried editing the PC protected page uk:Template:Convert/пісочниця. In a private window I could see the change to the template, and I could see the effect of the change. (I stuffed up my edit summary when I self-reverted—I meant to say that PC had no effect.) Johnuniq (talk) 03:45, 23 September 2024 (UTC)
In Ukrainian Wikipedia, there is no expectation that pages are stabilised by default, so the page contents of /sandbox page display the unreviewed page. Template review status is tracked on pages transcluding the template that use FlaggedRevs. So User:Johnuniq/convert would also show the page with unreviewed edits while the mainspace page won’t. stjn18:23, 24 September 2024 (UTC)
@Johnuniq Most of unreviewed changes are seen by unregistered user. It also doesn't depends if page has semi or full protection levels (however, to have fully protected page with unrewieved changes is rarest thing, because all administrator have rewiever rights). Only what matters is if a page has stabilization or not. Usually, if a page is highly proned to vandalism or have chosen as good article or featured article, administrator stabilize the page. In this case, all of unrewieved changes aren't seen by unregistered user. Usually, pages have special symbol to mark that they are stabilized, and the text on a save button would change from "save" to "write" or "write changes". Repakr (talk) 05:08, 24 September 2024 (UTC)
Thanks. I've never seen that approach. I was wondering whether unregistered users would see the effect of an unreviewed change to a module or template. One day you might test that with a stabilized module but we have enough to think about before continuing this. Johnuniq (talk) 05:36, 24 September 2024 (UTC)
I dunno where the corresponding source is, or whether this is a Wikipedia or MediaWiki issue, or if there is a defect logged and/or a workaround available. jnestorius(talk)16:05, 18 September 2024 (UTC)
The caption being set to display block has always been weird to me; the other display blocks in Minerva make some sense (but I also think I've played around with this before and come to the conclusion that it was necessary?? memory is weird on this point).
TLDR: The issue is the inline style adding display: inline-table which is interfering with Minerva's ability to make the table responsive on a mobile device. Please move this to a TemplateStyle so that it only applies at a suitable breakpoint and does not break the display on mobile.
Longer version: On mobile, since a table doesn't fit in the screen, presenting them to mobile devices becomes tricky. The way we approach this general in MediaWiki sites, it to convert the display property of all table elements to block-based layouts rather than table-based layouts. Applying display block to the table caption, will ensure that it does not require horizontal scrolling to be viewed and will span multiple lines if needed. While this might seem strange is a pretty widely recommended and sensible practice.
The bug here IMO is not the table caption - it's the use of display inline-table. If you load this article on a mobile device, and expand sections you'll see that this introduces horizontal scroll on the page e.g. the table breaks the content of the whole article. e.g. the whole article is not mobile friendly (note the whitespace to right of chrome in this screenshot: https://phabricator.wikimedia.org/F57532981).
Inline styles as always interfere with a lot of the logic we have to optimize content. As with dark mode where use of any kind of color can break dark mode display - using display or width or height properties interfere with the responsive behaviour and I would personally recommend always using mw:TemplateStyles to express these. 🐸Jdlrobson (talk) 00:07, 24 September 2024 (UTC)
Was the input box for Search the frequently asked questions in the help desk always this small? It has been squished by the button so much that it can't even display one character when I start typing.
That's messed up. I am able to reproduce it in Chrome. In Firefox, the search button text says "Search the freque...". I have worked around it by allowing the button to be on a second line. I wonder if something changed in the code for <inputbox>...</inputbox>. – Jonesey95 (talk) 00:57, 25 September 2024 (UTC)
Hmm, that's mw:Extension:InputBox? Doesn't seem like any related super recent changes there - there was an UI change in June though. I do not remember if Google Chrome ever displayed that search box correctly as I've only now paid conscious attention to it (and I don't frequent help desk, specially the top of the page, much).
After testing in preview at Wikipedia:Help desk/Header/sandbox, it seems that when I restore the break=no, even if I do width=500, or 50000, nothing actually changes from width=30...
Well, without the break=no it does resize past the 300 (and all the way off the side of the screen), a width=3 also has no effect. They do change a size attribute in the input box, but I guess because of what Izno said below it just has no effect when the button is in the same line? – 2804:F1...F5:930E (talk) 02:47, 25 September 2024 (UTC)
is what causes the issue today, since it's assuming that the table width containing the whole input box is "king", more or less. And it wants to display the content from the button more than the non-content in the form input.
(Without that CSS line at your browser, this naturally stretches the table to allow display of both the input and button. That's a feature of web tables but it causes issues in other ways sometimes.)
Two ways to fix it probably without asking for a change upstream. One is to make the side box bigger. I wouldn't generally advise this, since that has knockon effects for use in mobile. The other is to put the input and the button on different lines. Izno (talk) 02:29, 25 September 2024 (UTC)
Tools for formatting table cells
are there any toolbar buttons or add-ins which can be used/ added for users to format cells in a table, like changing cell BG colour? Anish Viswa 11:05, 23 September 2024 (UTC)
This is not I am looking for. Is there some option in WYSIWYG editor (add a toolbar) to select and change BG color of a cell or group of cells, like in MS Excel ? Anish Viswa 07:54, 25 September 2024 (UTC)
Mobile view: expand all headings
Is there a gadget, user script or way to get a button to expand all headings in mobile view? It's annoying to have to manually expand them all when you want to do "find in page" or just simply want to see the whole article </MarkiPoli> <talk /><cont /> 11:44, 25 September 2024 (UTC)
Yes, there's an option for that on Special:MobileOptions (accessible via top-left menu → Settings). [For anyone else reading this, note that the option only appears when using the mobile mode, and only on small-screen devices, since on larger devices the headings are already expanded.] Matma Rextalk12:36, 25 September 2024 (UTC)
Wow, never realised that! Although it doesn't seem to be a "button", just an option saying to expand all headings. That's fine, but a button would still be useful. Maybe someone could write a user script? </MarkiPoli> <talk /><cont /> 13:37, 25 September 2024 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
All wikis will be read-only for a few minutes on Wednesday September 25 at 15:00 UTC. Reading the wikis will not be interrupted, but editing will be paused. These twice-yearly processes allow WMF's site reliability engineering teams to remain prepared to keep the wikis functioning even in the event of a major interruption to one of our data centers.
Updates for editors
A screenshot of the interface for the Alt Text suggested-edit feature
Editors who use the iOS Wikipedia app in Spanish, Portuguese, French, or Chinese, may see the Alt Text suggested-edit experiment after editing an article, or completing a suggested edit using "Add an image". Alt-text helps people with visual impairments to read Wikipedia articles. The team aims to learn if adding alt-text to images is a task that editors can be successful with. Please share any feedback on the discussion page.
The Codex color palette has been updated with new and revised colors for the MediaWiki user interfaces. The most noticeable changes for editors include updates for: dark mode colors for Links and for quiet Buttons (progressive and destructive), visited Link colors for both light and dark modes, and background colors for system-messages in both light and dark modes.
It is now possible to include clickable wikilinks and external links inside code blocks. This includes links that are used within <syntaxhighlight> tags and on code pages (JavaScript, CSS, Scribunto and Sanitized CSS). Uses of template syntax {{…}} are also linked to the template page. Thanks to SD0001 for these improvements. [34]
Two bugs were fixed in the GlobalVanishRequest system by improving the logging and by removing an incorrect placeholder message. [35][36]
The API now enables 5,000 on-demand API requests per month and twice-monthly HTML snapshots freely (gratis and libre). More information on the updates and also improvements to the software development kits (SDK) are explained on the project's blog post. While Wikimedia Enterprise APIs are designed for high-volume commercial reusers, this change enables many more community use-cases to be built on the service too.
The Snapshot API (html dumps) have added beta Structured Contents endpoints (blog post on that) as well as released two beta datasets (English and French Wikipedia) from that endpoint to Hugging Face for public use and feedback (blog post on that). These pre-parsed data sets enable new options for researchers, developers, and data scientists to use and study the content.
In depth
The Wikidata Query Service (WDQS) is used to get answers to questions using the Wikidata data set. As Wikidata grows, we had to make a major architectural change so that WDQS could remain performant. As part of the WDQS Graph Split project, we have new SPARQL endpoints available for serving the "scholarly" and "main" subgraphs of Wikidata. The query.wikidata.org endpoint will continue to serve the full Wikidata graph until March 2025. After this date, it will only serve the main graph. For more information, please see the announcement on Wikidata.
@Quiddity (WMF) and SD0001: Regarding this change to syntaxhighlight, what would be the effect on pages like Help:Link and Help:Transclusion? Such pages have many examples of how wikitext is used, wrapped in <syntaxhighlight lang="wikitext">...</syntaxhighlight> where the intent is to show the markup and not the effect of using double square brackets and double braces. Will this be controllable with an attribute? If so, it should be opt-in, in order to not break all of the existing cases. --Redrose64 🌹 (talk) 06:56, 24 September 2024 (UTC)
Links are only applied within text detected by the syntax highlighter as comments (<!-- ... --> for lang=wikitext). The change is already live – if you don't see any effect now, there is no effect. – SD0001 (talk) 07:20, 24 September 2024 (UTC)
Example made with <syntaxhighlight lang="wikitext">...</syntaxhighlight>:
<!-- [[Alice]] is in a wikitext comment with lang="wikitext" so it is linked. It still displays the link brackets. -->[[Boc]] is not in a comment so it is not linked.
// [[Carol]] is not in a wikitext comment so it is not linked. It is in a CSS/JavaScript comment so it would have been linked with lang="CSS" or lang="JavaScript"
@PrimeHunter I'm not seeing any links in that example. Is there some preference that might be overriding it? --Ahecht (TALK PAGE)14:58, 25 September 2024 (UTC) Never mind, refreshing the page made the link show up. Must've been a glitch. --Ahecht (TALK PAGE) 15:04, 25 September 2024 (UTC)
Most (if not all) browsers will centre-align table header cells by default: if left-alignment is desired, it needs to be explicitly stated. --Redrose64 🌹 (talk) 17:24, 24 September 2024 (UTC)
.infobox-label,.infobox-data,/* Remove element selector when every .infobox thing is using the standard module/templates */.infoboxth,.infoboxtd{/* @noflip */text-align:left;}
The table header cells concerned match the first and third selectors here, so the declaration is applied to these cells. I don't think that Common.css is loaded in mobile view, so this rule is not applied. --Redrose64 🌹 (talk) 07:29, 25 September 2024 (UTC)
The latest run of Special:WantedCategories features another cluster of template-autogenerated nonsense, resulting from something that was done around {{WikiProject U.S. Roads}} within the past couple of days, rating articles for the importance level of "¬". Obviously that's not a real thing we actually expect to have, and this results from a coding or spelling error somewhere, but as that template imports things from an outside module I can't find the error to fix it as it isn't in the primary template itself. So could somebody look into making the following redlinked nonsense categories go away?
For some reason, all clickable links that used to be gray have now become blue like normal links. This includes section links and the thank button, among other things. It also makes short descriptions blue when using the search feature. They are all still the correct color on the desktop version. Is this intentional, and if not, can it please be fixed? Thanks, QuicoleJR (talk) 20:46, 26 September 2024 (UTC)
It also affects the notification when redirected to a different page, which is now hard to read because it is blue (or purple after clicked) on a black background. QuicoleJR (talk) 20:50, 26 September 2024 (UTC)
Let me know if there are any issues not covered by the bugs above. If so, please be specific and at minimum include URLs and description of area, and steps you followed. If you can please provide a screenshot (you can use phabricator upload if needed).
@Piotrus I think this could be straightforward for a bot to accomplish when both categories are single level, i.e only articles, but not when there are child categogies. If there are subcategories, then it's not trivial and a bot could be disruptive. Imagine if we could add Category:Archivists from Poland (Q7604592) to an article subject, and it would populate specific language editions under certain conditions. I am holding out for wikidata improvements to address this. Ironically this convo will get archived by a bot later ;) ~ 🦝 Shushugah (he/him • talk) 11:18, 27 September 2024 (UTC)
Hello everyone, a small change will soon be coming to the user-interface of your Wikimedia project.
The Wikidata itemsitelink currently found under the General section of the Tools sidebar menu will move into the In Other Projects section.
We would like the Wiki communities feedback so please let us know or ask questions on the Discussion page before we enable the change which can take place October 4 2024, circa 15:00 UTC+2.
More information can be found on the project page.
I've raised a similar situation at Template:Unreferenced. This is because the templates use Template:Ambox. Creating an exact duplicate template just so other namespaces can be categorized is a horrible idea. Instead, the system behind categorization at the base level should be changed. The template shouldn't care which namespace it is placed on for categorization. Gonnym (talk) 09:53, 27 September 2024 (UTC)
@Anomie: Aha! So the capability already exists! So what I need to do is update the talk page of {{overcoloured}} to suggest replacing the use of {{DMCA}} with {{DMC}} or {{DMCFACT}} since I believe we would want to track all or most overcolored situations, not just those occurring on articles, and attempt to get consensus on that change to the template. Thank you! Considering this matter solved. Thisisnotatest (talk) 20:01, 27 September 2024 (UTC)
@Thisisnotatest: If something is wrongly categorised, and there is a possibility that the cat is due to the effects of a template, a purge won't help because it doesn't update the link tables. A WP:NULLEDIT is the thing to try. --Redrose64 🌹 (talk) 17:23, 27 September 2024 (UTC)
What happened to the categories at the bottom of articles on the mobile version of the site? You finally added them, then they disappeared for a while, then they came back, then they disappeared for good and that was years ago. Please bring them back and keep them there, there is no reason to not have them there and it is extremely inconvenient 2603:7080:8140:8A60:14E:FF29:2359:5592 (talk) 12:42, 28 September 2024 (UTC)
Two separate notices when editing an old revision of an article?
Two notices about editing an old revision on the English Wikipedia on September 26, 2024Screenshot of editing old headers from 2020
Have we always had two separate notices when editing an old revision of an article? If so, why? If not, what was changed and when? ElKevbo (talk) 23:07, 26 September 2024 (UTC)
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)
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)
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.
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)
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)
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.
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)
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)
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)
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)
D'oh! I just realized that I should've used |all=yes.
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)
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)
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)
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)
NewUsers now blue-linking everyone’s contribs pages
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)
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:
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)
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)
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. [38]
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. [39]
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. [40]
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?
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
+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)
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)
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)
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)
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)
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)
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)
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)
Preview box
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)
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)
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)
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).[41] 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)
Thanks! I spent way too long trying to figure that out, and would've spent a lot longer without your help! Sdkbtalk15:38, 2 October 2024 (UTC)
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)
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)
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)
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)
Embedded anchors in tables
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)
@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)
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)
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)
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)
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)
Automatic citation generation isn't working?
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)
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.
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)
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>
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)
@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)
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)
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)
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)
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)
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)
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)
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)
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)
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. — xaosfluxTalk13:07, 25 September 2024 (UTC)
@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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
Can someone not a maintainer read a file on toolforge?
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)
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
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)
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)
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)
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)
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)
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)
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)/Archive_215) 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)
@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)
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)
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)
Interlang bug
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)
@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)
@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)
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)
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)
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)
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)
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)
Some Wayback Machine/Internet Archive links now failing?
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)
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)
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)
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)
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)
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)
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)
Adding Template Data to a template makes a parameter usage report available. Here's one for {{cite archive}}: [44] 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: [45]Rjjiii (talk) 03:21, 5 October 2024 (UTC)
How do title bar colors get into an infobox?
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.
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}}.
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)
Not sure if here or the Help desk is the right place... Anyway, I've two questions, please:
Is there a way (e.g., a tool) to extract diffs without going through the page history?
When I click on the timestamp of a signature, I get a comment-specific link (e.g., [46]). 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?
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 Rextalk17:19, 4 October 2024 (UTC)
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)
which is {{diff|prev|1249444013|4 ott 2024, 23:16}} and doesn't work. I have to turn it into a {{diff2}} by adding a "2" and removing "prev", to get this:
By the way, the database behind the comment links includes the diff numbers of the revision that added the comment (see docs here), although only for comments that were posted since the comment links were enabled – we weren't able to process all historical revisions, it would have taken forever [I worked on this feature with the Editing team about a year ago]. So you could run a SQL query like this to look it up:
…but we never got around to building a user interface for that (Special:FindComment only shows the latest revisions of pages containing the comment, not the oldest), and we also apparently never got around to setting up replication of those tables to the public replicas (although they could be replicated, as noted in T303295#7850298), so you can't even build a Toolforge tool to do it right now. These things could be done with a bit of effort, though… Matma Rextalk20:30, 5 October 2024 (UTC)
And I've only been able to make very simple substitutions. I'm familiar with regex etc. I must be missing something fundamental. Thanks. Johnjbarton (talk) 20:22, 5 October 2024 (UTC)
These look the same to me, but somehow no match? I think this is related to my failure when using a parameter for the source. Johnjbarton (talk) 21:58, 5 October 2024 (UTC)
And one other issue I accidently discovered: AFAICT you can't match on <ref>...</ref> because the ref tag is somehow rendered to a <span>...</span> before the match. Johnjbarton (talk) 22:27, 5 October 2024 (UTC)
Refs get mw:Strip markers and interact oddly with some features. Consider for example {{#invoke:string|replace|source=<ref>U</ref>|pattern=U|replace=V}} which produces: '"`VNIQ--ref-00000129-QINV`"'. Huh? The replacement doesn't work inside <ref>...</ref> but it does work on the strip marker where it changes UNIQ...QINU to VNIQ...QINV. This exposes the now incorrect strip marker. The reference still works in spite of this but there is no link to it. PrimeHunter (talk) 23:47, 5 October 2024 (UTC)
Yes, I stumbled into that one too ;-) I found Template:Strip tags for giving the text other than the refs so I was trying to find a way to get the inverse function, just the content not the refs. I succeeded in part but my solution is not robust, too many ways to fail. I think now I will regroup and plan to edit the input data into a form that is easier to format with templates. Johnjbarton (talk) 00:16, 6 October 2024 (UTC)
Why is our sister link to Kaesong on Wikivoyage starred?
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 here04:20, 26 September 2024 (UTC)
@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)
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)
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)
@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)
@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)
(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)
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 here03:57, 4 October 2024 (UTC)
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)
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)
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)
@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 here03:55, 4 October 2024 (UTC)
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)
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)
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. —Cryptic13:22, 4 October 2024 (UTC)
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)
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. —Cryptic15:16, 4 October 2024 (UTC)
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. —Cryptic16:19, 4 October 2024 (UTC)
Sorry for being away from this thread for a while. None of this is a Wikivoyage problem, and there's nothing that we can do about it at Wikivoyage, as far as I can tell. It seems to be a Wikidata problem. Ikan Kekek (talk) 20:30, 6 October 2024 (UTC)
How do I delete a section (blank entire section) from my personal user talk page? I used to do it with a script from times before the software upgraded to include new stuff (e.g. subscribe button, 'Latest comment: 22 minutes ago | 1 comment | 1 person in discussion' and the like. Gryllida (talk, e-mail) 07:46, 7 October 2024 (UTC)
@Gryllida: Edit the section, click anywhere in the edit box, then do: Ctrl+A← BackspaceAlt+⇧ Shift+S. You can use Delete instead of ← Backspace if that's easier for you. --Redrose64 🌹 (talk) 09:45, 7 October 2024 (UTC)
There is problem in this list (section "Minimum wages by country" and "Minimum wages by country (other countries)") to sort data by "Net (EUR)" and "Net (PPP)". What to do? Eurohunter (talk) 15:07, 6 October 2024 (UTC)
@Eurohunter you have described everything BUT the 'problem'. Never assume that others are seeing or experiencing the same thing as you, and make full and extensive descriptions of the problem that you are encountering. —TheDJ (talk • contribs) 19:04, 6 October 2024 (UTC)
The third click on EUR sort buttons takes you back to the initial sorting, which is a sorting by country name. It is not a bug, it is a feature. Uwappa (talk) 09:35, 7 October 2024 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
Communities can now request installation of Automoderator on their wiki. Automoderator is an automated anti-vandalism tool that reverts bad edits based on scores from the new "Revert Risk" machine learning model. You can read details about the necessary steps for installation and configuration. [53]
Updates for editors
Translators in wikis where the mobile experience of Content Translation is available, can now customize their articles suggestion list from 41 filtering options when using the tool. This topic-based article suggestion feature makes it easy for translators to self-discover relevant articles based on their area of interest and translate them. You can try it with your mobile device. [54]
It is now possible for <syntaxhighlight> code blocks to offer readers a "Copy" button if the copy=1 attribute is set on the tag. Thanks to SD0001 for these improvements. [55]
Customized copyright footer messages on all wikis will be updated. The new versions will use wikitext markup instead of requiring editing raw HTML. [56]
Later this month, temporary accounts will be rolled out on several pilot wikis. The final list of the wikis will be published in the second half of the month. If you maintain any tools, bots, or gadgets on these 11 wikis, and your software is using data about IP addresses or is available for logged-out users, please check if it needs to be updated to work with temporary accounts. Guidance on how to update the code is available.
Rate limiting has been enabled for the code review tools Gerrit and GitLab to address ongoing issues caused by malicious traffic and scraping. Clients that open too many concurrent connections will be restricted for a few minutes. This rate limiting is managed through nftables firewall rules. For more details, see Wikitech's pages on Firewall, GitLab limits and Gerrit operations.
This is not a new issue (see previous discussions here and here for example), and I don't frequent the technical pump often, but the extremely valuable Refill tool has been non-functional for months (years?). Any updates? And, if it's broken/abandoned for good, is there a similar tool that can quickly convert bare URLs into formatted citations, and/or combine duplicate citations? Furthermore, is there a clear list of handy editing tools somewhere on Wikipedia? I've been a regular editor for well over a decade, so if there is one, I've overlooked or forgotten about it. There are a lot of problems on Wikipedia: prioritizing tools, and making them easily visible to editors who don't have a computer science degree, should be a top priority. Cheers, --Animalparty! (talk) 00:29, 8 October 2024 (UTC)
After reading [62] 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)
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)
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)
@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)
I asked a developer and they suggested that the original error was likely due to the user switching browser-tabs while the extension is scanning the page. Quiddity (WMF) (talk) 00:38, 8 October 2024 (UTC)
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)
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)
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)
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)
@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)
Sigh... Where is this guesswork coming from? meta:CopyPatrol says it uss User:EranBot that uses both google trough Earwin and Turnitin. Read both links. Could you stop this guesswork nonesence and stick to facts? You are starting to annoy me. Also if you put an diff into earwigs tool it checks the whole article, not just the diff in question. Do not just repeat nonesence when proven otherwise. Snævar (talk) 09:37, 8 October 2024 (UTC)
Something that may be related - there are also some icons in the interface that aren't showing up on mobile (Firefox Nightly and Firefox). The two I've noticed are the "watch" icon on pages I'm watching, and the red alert circle that displays in the top bar if there's notifications. Suntooooth, it/he (talk/contribs) 13:43, 8 October 2024 (UTC)
I previously struggled with a maplink situation where the answer was to wait a few days for Kartographer to sort itself out. CMD (talk) 12:32, 8 October 2024 (UTC)
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)
*I unarchived this to reply*. @Mathglot: Sorry I didn't see this earlier, but your description reminded me of a recurring (possible) bug affecting the abusefilter - I checked and it does seem like your edit is related: your edit triggered the monitoring filter 9 times separately from the edit.
In progress I asked over at User_talk:Giftpflanze#toolforge:Linksearch
Resolved
Administrators can now test the temporary accounts feature on test2wiki. This was done to allow cross-wiki testing of temporary accounts, for when temporary accounts switch between projects. The feature was enabled on testwiki a few weeks ago. No further temporary account deployments are scheduled yet. Temporary Accounts is a project to create a new type of user account that replaces IP addresses of unregistered editors which are no longer made public. Please share your opinions and questions on the project talk page.
Please review and vote on Focus Areas, which are groups of wishes that share a problem. Focus Areas were created for the newly reopened Community Wishlist, which is now open year-round for submissions. The first batch of focus areas are specific to moderator workflows, around welcoming newcomers, minimizing repetitive tasks, and prioritizing tasks. Once volunteers have reviewed and voted on focus areas, the Foundation will then review and select focus areas for prioritization.
Courtesy link: User talk:Mathglot § Ships of ancient Rome
Polygnotus (talk) 22:19, 19 August 2024 (UTC)
— GhostInTheMachine talk to me 12:49, 13 September 2024 (UTC)
Resolved
. @Trizek (WMF):. Mathglot (talk) 17:49, 20 September 2024 (UTC)
Done. Trizek, I've gone ahead and made that change; thanks. Mathglot (talk) 21:53, 22 September 2024 (UTC)
. 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)
