Hi there. Could I get some help for improving Module:Sports table/Badminton team. I try to use these codes, but there are some columns with zero, which should be not shown, as the data might not be available. So I expect the column would be: Pos, Team, Pld, W, L, MF, MA, MD, Pts, Qualification (for uncomplete table, activated by "point_for_against_style=none". Any help would be appreciated. Regards. Medelam (talk) 13:49, 19 October 2021 (UTC)

Pos	Team v t e	Pld	W	L	Pts	Qualification
1	Indonesia	3	3	0	3	Advanced to knockout stage
2	England	3	2	1	2
3	Malaysia (H)	3	1	2	1
4	Japan	3	0	3	0

Looks like you want |point_for_against_style=none and |game_for_against_style=none, which removes the header columns. However there doesn't seem to be code to disable the data rows in Module:Sports_table/Badminton_team. I've changed your example (above) and will I'll see if I can get it to work in the sandbox. —  Jts1882 | talk  14:32, 19 October 2021 (UTC)

@Medelam: Is the above now what you require? —  Jts1882 | talk  14:41, 19 October 2021 (UTC)

@Jts1882: Yes, that is exactly what I want. Appreciate your effort. Thank you and regards. Medelam (talk) 14:44, 19 October 2021 (UTC)

I've put it live. The header code was also hiding the points columns if the games columns were hidden, so I've done the same with the country rows for consistency. So |point_for_against_style=none is redundant when |game_for_against_style=none is set. —  Jts1882 | talk  15:18, 19 October 2021 (UTC)

A few project pages - and not all of them - have big arrows to click for "Skip to Top" and "Skip to Bottom". For me personally, they're just blocking text I want to read. How are these inserted on project pages, and how can I adjust so I don't have to see these arrows. Thanks. — Maile (talk) 15:53, 19 October 2021 (UTC)

@Maile66 see ((Skip to top and bottom)) - I think this is the template you're referring to. There are instructions there on how to hide them in your CSS. Nthep (talk) 16:01, 19 October 2021 (UTC)

Looks like it worked. Thanks. — Maile (talk) 16:43, 19 October 2021 (UTC)

I volunteered to take over maintenance of WP:Refill as the original developer was no longer interested/able to do so. I am set up with Toolforge access via PuTTY etc. I'm having difficulties getting the code to build and run locally on my dev machine. I could really do with a Python dev to help me deal with NPM versioning issues (breaking changes in dependencies). Ideally, it would be someone who would be willing to be around longer than just to get me going, i.e. to field occasional subsequent questions. Hopefully, Curb Safe Charmer (talk) 16:54, 19 October 2021 (UTC)

@Curb Safe Charmer: Hey! I got that running locally not that long ago what's broken? ~TheresNoTime ^{(to explain!)} 17:04, 19 October 2021 (UTC)

Replied on TheresNoTime's talk page. Thanks - this is hopefully the help I need - if not, I will post again here. Curb Safe Charmer (talk) 20:06, 19 October 2021 (UTC)

Just a note, if this gets into Pythonic Madness I may have to poke someone like Tamzin ~TheresNoTime ^{(to explain!)} 20:09, 19 October 2021 (UTC)

This seems to have started today. When I point my mouse at "hist" on my watchlist the pop-up shews more-or-less as usual, but with vertical white bars between cur prev | time | username | section. You can see a picture of it here. They are not visible if I switch the gadget off. DuncanHill (talk) 19:08, 19 October 2021 (UTC)

@DuncanHill: there was an update to Wikipedia:Tools/Navigation popups today - is that what you are using? Perhaps there is a conflict with something in MediaWiki:Gadget-Blackskin.css. As the former has ~55000 users and the later has ~6400, I'd rather someone propose a change to blackskin then rollback navpops though. — xaosflux ^Talk 19:20, 19 October 2021 (UTC)

@Xaosflux: Yes, Navigation Pop-ups. DuncanHill (talk) 19:24, 19 October 2021 (UTC)

Apparently blackskin.css overrides the table background, and the cell background, but not the background-color of the table rows —TheDJ (talk • contribs) 19:24, 19 October 2021 (UTC)

@Xaosflux: we can just add this into the table section of the blackskin.

table tr { 
    background-color: #000000!important;
    color: #00dd00!important;
}

—TheDJ (talk • contribs) 19:34, 19 October 2021 (UTC)

@TheDJ: thank you for the markup; @DuncanHill: I updated blackskin, please check in about 5 mins? — xaosflux ^Talk 20:44, 19 October 2021 (UTC)

@TheDJ: and @Xaosflux: Thank you, works as expected now. DuncanHill (talk) 20:59, 19 October 2021 (UTC)

What is it's equivalent? I don't find the element anywhere in the page and thus almost no user script in Wikipedia:User scripts/List#Editing doesn't work for me. The Wikipedia:User scripts/Guide seems to be written for the 2010 editor and isn't helpful for me in editing mode, when I try to develop a script on my own. Thanks for any help! — DaxServer (talk) 13:49, 20 October 2021 (UTC)

wpTextbox1 is present alright for the 2017 wikitext editor. You should use jQuery.textSelection API for textbox interactions as they'd work independently of the type of source editor. – SD0001 (talk) 15:06, 20 October 2021 (UTC)

@SD0001 Thanks for the reply. I must have been doing something so wrong!! — DaxServer (talk) 15:21, 20 October 2021 (UTC)

After tagging an orphaned PDF for WP:F10, I noticed that the message that Twinkle posts on the uploader's talk page (((Db-badfiletype-notice)) makes reference to Microsoft Word documents as a potential bad file type. But I thought I'd read somewhere that there's technical limitations in place that prevent the uploading of word documents (and generally non-image files other than PDFs). I guess if there are legacy ones hanging around, it might not be bad to keep the wording, but is it going to be possible to upload such file types? If not, I can change the template wording. Hog Farm _Talk 06:12, 21 October 2021 (UTC)

@Hog Farm: you can see the list of supported file extensions here (click "make request" after ensuring we're not trying to trick you in to something nefarious - notably the action= in the left pane should say query to show it is only trying to read things). I suppose technically this isn't examining the file "type" just the name, but it is something to go off of. Improvements to that system are discussed in phab:T42479 and many linked tasks therein. — xaosflux ^Talk 11:44, 21 October 2021 (UTC)

Had to look up what some of those file extensions meant. Mostly a bunch of obscure audio/video formats. Looks like the only F10-eligible filetype is .pdf and possibly .djvu. Hog Farm _Talk 14:41, 21 October 2021 (UTC)

I was wondering this script, found on Customizing watchlists for the Username:common.css files is safe to apply? Qwerty284651 (talk) 23:34, 20 October 2021 (UTC)

a [title="pagename"] {
    color: white;
    background: red;
    font-size: 150%;
}

Qwerty284651 (talk) 23:34, 20 October 2021 (UTC)

@Qwerty284651: yes, that would be "safe" to use on your User:Qwerty284651/common.css page. — xaosflux ^Talk 23:44, 20 October 2021 (UTC)

@Xaosflux: I tried using both the full URL permalink and the abbreviated name of an actual Wiki page, but it gave an error stating Warning: Unqualified attribute selectors are known to be slow. I am not good with scripts, so I don't understand what it wants from me. Could you help me out, please? Qwerty284651 (talk) 00:10, 21 October 2021 (UTC)

The warning message is letting you know that since the [title="pagename"] selector will match against any HTML element, it will be slow to check all of them for the title attribute in question. You should remove the space between a and [title="pagename"], so only anchor elements will be checked. (I updated the Customizing watchlists page accordingly.) isaacl (talk) 04:37, 21 October 2021 (UTC)

Indeed, this isn't a great script - but it isn't "dangerous". — xaosflux ^Talk 10:57, 21 October 2021 (UTC)

Thanks, Xaosflux. I just run into this script, whilst looking for a way to highlight certain pages in my watchlist for easier navigation, but wasn't sure what was the problem with the error it was displaying. Thanks. Cheers, Qwerty284651 (talk) 11:32, 21 October 2021 (UTC)

@Xaosflux Under pagename do I use the wikilink short version or the full URL permalink? Qwerty284651 (talk) 20:19, 21 October 2021 (UTC)

The "title" attribute on an HTML element is what shows up in the popup tooltip when you hover over the element. Thus you should use whatever shows up when you hover over the link. isaacl (talk) 21:15, 21 October 2021 (UTC)

(edit conflict) @Qwerty284651: I moved this thread from WT:VPT, which is the talk page for discussing improvements to this page - basically, whether to alter the archive settings, almost nothing else goes there.

Anyway, please note that what you have provided above is not a script, it is a CSS rule. CSS rules, generally speaking, are harmless - the worst that could happen is that you make the whole page invisible. None of the three declarations in your rule goes anyway near to sdoing that. --Redrose64 🌹 (talk) 21:18, 21 October 2021 (UTC)

@Redrose64: Thanks for clarifying it for me. Qwerty284651 (talk) 22:34, 21 October 2021 (UTC)

Hi there! I've been working on expanding bare URLs in references recently. However, there have been lots of URLs that point to an external file (PDF, image, etc.), where automatic reference generating cannot work normally to grab information such as titles. Then what can I do to expand those references? Maybe, upload the original files? Or something else? -- UNITE TOGETHER, STRIVE FOR SURVIVAL! 02:53, 16 October 2021 (UTC)

I think those have to be handled manually. Whatamidoing (WMF) (talk) 23:49, 21 October 2021 (UTC)

FYI in the last year or so I've noticed that refill2 is now formatting a few PDFs. Reflinks can format quite a few of them and can also mark some that have gone dead with a "dead link" template. But, as Whatamidoing points out, there are still tons of them that have to be formatted manually. MarnetteD|Talk 00:00, 22 October 2021 (UTC)

Hi. The auto citation tool is having problems citing pages from the IGN site. See the example: "<ref>((Citation|last=pm|first=Craig HarrisUpdated: 12 May 2012 11:41 amPosted: 20 Oct 2008 10:14|title=Legend of Kage 2 Review - IGN|url=https://www.ign.com/articles/2008/10/20/legend-of-kage-2-review|language=en|access-date=2021-10-18))</ref>". Note that the "last" and "first", which serve respectively to put the last and first name of the author of the article, are showing quite wrong information. And this bug not only affects the enwiki, but other wikis, like ptwiki, are also being affected. ✍A.WagnerC (talk) 17:22, 18 October 2021 (UTC)

This is likely an issue with the Zotero configuration for IGN. See zotero.org for more information. Izno (talk) 00:59, 19 October 2021 (UTC)

@Scann or @Diegodlh could probably tell you more about what the problem is. Whatamidoing (WMF) (talk) 23:56, 21 October 2021 (UTC)

Thanks for flagging this. I'll defer to Diego to explain the problem but in the meantime I've added the URL to our list of "problematic URLs" to test with Web2Cit. --Scann (talk) 00:29, 22 October 2021 (UTC)

I do have a possible issue that may be rooted in Wikipedia software. Or in the construction of lists with Wikipedia style elements. Some larger lists do not "nicely" print. With nicely I mean you can get the entire data to printer output without manually resizing (scaling). Fit to page size should do that, but it doesn't. While this can be OS related, I am a bit puzzled that it does not even work for PDF output (instead of printer output). As PDF carries an outer frame, in which all elements are placed, in theory it should not occur that certain information gets outside that frame.

This is Linux Mint (Ubuntu) version 19, and I see the issue with both the printer driver for Canon MX925 (which is a very reliable, well written driver). I have to scale below 87% (!) to get the entire content of a given page into that page without overspill at the right hand side. At the moment, I do not have a Windows machine at hand to verify this behaviour on Windows.

Browser is an up-to-date Firefox 93. Printing is done via Firefox' print function, which utilizes all installed drivers and a built-in PDF export. Mint/Ubuntu also offers PDF printer export as a driver, so I got three options: Canon, PDF export driver, built-in Firefox PDF export. All three show the issue...

The best example to showcase this is the list of Doctor Who serials: https://en.wikipedia.org/wiki/List_of_Doctor_Who_episodes_(1963%E2%80%931989)

Thanks a lot. 2001:A61:BAC:F001:9C64:F645:CAA3:9003 (talk) 10:01, 22 October 2021 (UTC)

When an article at en-wiki doesn't exist in any other language, I usually get a few "suggested" languages to translate into in the left sidebar under the 'Languages' heading, where language links would appear had there been articles in other languages. In my case, French is one of those languages that often appears. The text in the left sidebar is français, exactly as it would be if a fr-wiki article existed. (Well, not exactly; the font is a lighter shade; approximately #72777D.) But the hover text is different.

Hovering over français in the language links section of the sidebar when there is no French article pops up the tooltip "Translate this page into français". Clicking the link pops up a dialog box, which starts off with the bold heading, This page does not exist in français yet. Do you want to create it?

This is English Wikipedia, and in my opinion, both the tooltip and the dialog box should both be written entirely in English (with the possible exception of adding a parenthetical appositive; e.g., "Translate this page into French (français)" would be fine. I don't have an objection to the long-standing practice of leaving the rendered text of language names in the list of language links in the native language; my question/complaint regards the language of the tooltip text, and of the pop-up dialog box. Thanks, Mathglot (talk) 20:12, 21 October 2021 (UTC)

This seems like a reasonable task to put in Phabricator, starting with the Language-team team project. They should be able to sort it into an appropriate component project. Izno (talk) 20:45, 21 October 2021 (UTC)

We can also do it locally in MediaWiki:Cx-entrypoint-title and MediaWiki:Cx-entrypoint-dialog-page-doesnt-exist-yet by testing $1. We don't appear to currently have a feature to get the language code from the native language name like français, but we could make it. PrimeHunter (talk) 21:50, 21 October 2021 (UTC)

Realistically, this suggestion is primarily intended for people fluent in the destination language - if you can't easily read the name of the destination language in its native format - you probably shouldn't be trying to create articles on that other project. Am I missing a part of this? — xaosflux ^Talk 13:31, 22 October 2021 (UTC)

Hi all, I've found that sometimes the quickest way of seeing if an issue is just me or not just me is by mentioning it here and waiting for the screaming.

Can anyone else confirm? ~TheresNoTime ^{(to explain!)} 14:06, 22 October 2021 (UTC)

@TheresNoTime yep, confirmed - interestingly, when I tested on a page I had watchlisted before enabling discussion tools, the bug didn't trigger. When I tested watching a page after enabling discussion tools, things happened exactly as you describe. firefly ( t · c ) 14:12, 22 October 2021 (UTC)

Is there is a list of all available hooks (mw.hook) or is there a listener that I can hook into to listen to all hook fires? I've looked at mw:Manual:Hooks, but that doesn't seem what I'm looking for. An example is User:BrandonXLF/EasySummary.js, where the script is hooked into ve.saveDialog.stateChanged Thanks! — DaxServer (talk) 11:48, 22 October 2021 (UTC)

The core ones are listed here in the mw.hook documentation. Other ones are considered to be 'private' but most can easily be found with codesearch. —TheDJ (talk • contribs) 13:19, 22 October 2021 (UTC)

If you just want the names of all the hooks that have previously fired on the page you're on, you could also go to the function definition for mw.hook in your browser's dev tools and set a breakpoint on return hooks[name] right at the top of the function, hit the breakpoint by running mw.hook(), then look at the keys in the hooks object. – Rummskartoffel 14:58, 22 October 2021 (UTC)

Thanks @TheDJ and @Rummskartoffel. Both your solutions're quite useful! — DaxServer (talk) 16:45, 22 October 2021 (UTC)

Hello! I'm seeing something rather peculiar. In Special:PageHistory/Template:COVID-19 data/data, there are links to User:TolBot/Task 5, a soft redirect to Meta-Wiki, in my bot's edit summaries — but, despite the page existing, the links are red. When I click on a diff, the link is blue, and anywhere outside of an edit summary it's also blue. I've tried with safemode, so I don't think it's me. Can anybody else verify this or help me figure out what's going on? Thanks. Tol (talk | contribs) @ 21:57, 15 October 2021 (UTC)

I see the link in the most recent edit as blue, and the others as red. Moving to the previous 100, all are blue. Filtering by date to exclude today's two changes, all are blue. It looks like a minor bug. Certes (talk) 22:17, 15 October 2021 (UTC)

I only see one "Task 5" blue link at the history of Template:COVID-19 data/data. It is the most recent. The reason it is blue is that the wikitext is [[m:User:TolBot/Task 5|Task 5]] whereas the others omit m:. I tried to purge the history page but of course it only purged the template and that did not help. Weird. I don't see how it's related, but I asked about a red link problem here. Johnuniq (talk) 22:44, 15 October 2021 (UTC)

There was recently an overhaul of how edit summaries ("comments") are formatted on history pages, this might be another regression from that. I would suggest filing a bug in Phabricator for this, as the output clearly is wrong given User:TolBot/Task 5 exists on this wiki. Legoktm (talk) 05:50, 16 October 2021 (UTC)

And notably on other pages, such as the changevisibility controls page, the show as blue links. So looks like a bug of sorts on the history view page. — xaosflux ^Talk 15:46, 16 October 2021 (UTC)

Thanks, everyone. I've filed a task. Tol (talk | contribs) @ 21:54, 18 October 2021 (UTC)

This also happens for user pages that don't exist here but do exist at Meta, when a cross-wiki transclusion occurs - see for instance the two links to Explicit's user page in these edits. --Redrose64 🌹 (talk) 12:08, 23 October 2021 (UTC)

This anon is vandalizing and leaving non-linear edit summaries 93.106.154.191 (talk · contribs · deleted contribs · filter log · WHOIS · RDNS · RBLs · http · block user · block log) which are visible in his contribution history. I am using Windows 10 Pro/64 w/ Firefox current version. It is also visible with Chrome. Should a fix be made to Wiki's html generator?

Adakiko (talk) 07:08, 23 October 2021 (UTC)

See Zalgo text. Nardog (talk) 07:18, 23 October 2021 (UTC)

This could make for some interesting vandalism. Might need to request revdels so that other's edit summaries are readable? Adakiko (talk) 07:24, 23 October 2021 (UTC)

So far, all of the "offending" edits have been at WP:Sandbox, a page to which we extend a great degree of freedom; it is generally acknowledged that no edits to this page can constitute vandalism as it is normally understood. So long as they're not committing a great Wikicrime - such as making an attack page or posting a massive copyvio - we generally let it be. --Redrose64 🌹 (talk) 11:36, 23 October 2021 (UTC)

While in this case it appears not to be vandalism and may even be a legitimate test edit , the edits do present a problem which we may need to find solutions, to ensure that if someone does something similar on non-sandbox pages, it doesn't effect the usability of the page or of the page history to other legitimate users. Ideally we shouldn't have to rely on friendly admins rev-deleting things to fix issues like this.Nigel Ish (talk) 12:02, 23 October 2021 (UTC)

I doubt this kind of vandalism occurs frequently enough to warrant any preventative measures. You have to know how to do it, and there are much easier and quicker ways to vandalise. – Rummskartoffel 13:10, 23 October 2021 (UTC)

Hi, could someone take a look at why the list of archives isn't displaying at the top of Talk:Air Koryo? I'm guessing it's due to the strange naming convention, e.g. Talk:Air Koryo/2012/Archive 1, but not sure how to fix it. -M.nelson (talk) 10:23, 23 October 2021 (UTC)

Because you didn't put (and configured) one of the templates that do just that?

User:MiszaBot/config#After_you_have_set_up_archiving. MarMi wiki (talk) 15:21, 23 October 2021 (UTC)

 Fixed. Those archives are very small and should probably be merged into one archive with a standard name. – Jonesey95 (talk) 15:29, 23 October 2021 (UTC)

Thank you. Good point, the standard format would be better; I'll try resetting it and then ((talk header)) might list them without an additional template. -M.nelson (talk) 15:57, 23 October 2021 (UTC)

I received a message on User talk:BattyBot claiming that my bot created Draft:Manathi P Ganesan. However, my bot doesn't create drafts. I looked at the draft history, and the only edit listed is my bot's edit to add ((Draft categories)). What happened to the rest of the edit history, and how can it be restored? Thanks! GoingBatty (talk) 02:38, 24 October 2021 (UTC)

Based on the logs, the draft was history-merged into a user sandbox page, which basically moved all revisions to that page. —A little blue Bori v^_^v ^{Jéské Couriano} 02:53, 24 October 2021 (UTC)

(edit conflict) Anthony Appleyard used Special:MergeHistory to move the rest of the history to User:Mc.balamurugan/sandbox. It's still there, so there's nothing to restore. * Pppery * _{it has begun...} 02:53, 24 October 2021 (UTC)

Click "View logs for this page" at top of the page history to see what happened. PrimeHunter (talk) 11:38, 24 October 2021 (UTC)

When edited, dab Morgan White claims that "There is a draft for this article at Draft:Morgan White". That page does exist, but it's a redirect to Morgan White (gymnast). I see why ((Editnotices/Namespace/Main)) is invoking ((Draft at)), but could we handle such cases better? Pinging BD2412 and SD0001 who contributed to a previous discussion. Certes (talk) 22:49, 23 October 2021 (UTC)

I have gone ahead and moved the draft title to Draft:Morgan White (gymnast) for consistency. BD2412 T 22:52, 23 October 2021 (UTC)

Feel free to suggest an edit at template talk:Editnotices/Namespace/Main. The logic has become rather complicated, though maybe not to the extent that a Lua module is needed. – SD0001 (talk) 11:51, 24 October 2021 (UTC)

Thanks for the replies. This odd-looking behaviour seems correct then: the template is right to draw our attention to the minor issue of a malplaced redirect. If someone were preparing a BCA or other replacement for the dab, I'd want to know about it. Certes (talk) 14:54, 24 October 2021 (UTC)

I made this edit just to fix a template date in a article split request so the article would be correctly categorized by the month/year. This got listed under Articles to be split at Wikipedia:WikiProject Singapore as proposed by me when it was in fact an IP that first added ((split-section)). Another editor did a split, without there having been any discussion. After that, they discovered it was suggested by an IP, and mentioned on my TP that they were mislead and may not have done the split had they realized the request came from an IP (not to disparage all IPs). Regardless, the "proposer" of the split was listed incorrectly. I don't know what templates/bots are involved in this so asking here if this can be "fixed". MB 19:58, 24 October 2021 (UTC)

@MB: I think you are referring to this edit - and think that it should be better? If so, please bring it up at User talk:AAlertBot and / or Wikipedia talk:Article alerts to see how that could be improved. — xaosflux ^Talk 20:19, 24 October 2021 (UTC)

Asked at Wikipedia talk:Article alerts. Thanks. MB 20:26, 24 October 2021 (UTC)

Hi. Does anyone know of a GNU General Public License flashcard software program that can be used to run, share, and modify on Wikipedia? If so, please paste the code in your response. I would want to test it in the sandbox and then eventually place it on some of the glossaries and make flashcards within Wikipedia using the terms and definitions. The reader would be able to study the flashcards without leaving the page. It is an idea I have wanted to try for a long time. I think it would be a big hit. LearnMore (talk) 20:24, 22 October 2021 (UTC)

Wikiversity has learning resources about Help:Quiz-Simple

@LearnMore: Wikipedia usually doesn't support that kind of interactive content, historically because it doesn't print in a reasonable way and is difficult to proofread. You can make quizzes on the Wikiversity sister project and link them as shown here. There is another technical reason that you don't want to host actual flashcards inside Mediawiki or its extensions: spaced repetition, a useful way to sequence flashcards, requires storage that doesn't fit into the Mediawiki database schema, nor in JavaScript storage in a way that would let a user migrate between browsers e.g. on different devices, and for large decks of flashcards such as for language vocabulary, it's not clear whether you could prevent bumping up against local storage limits even if you limited users to one browser. One very popular and widely supported free cross-platform flashcard app is Anki, decks of which you can link to with their AnkiWeb service which has limited collaboration features. 71.204.166.188 (talk) 04:43, 23 October 2021 (UTC)

Thank you very much for the response. I appreciate it. LearnMore (talk) 21:49, 24 October 2021 (UTC)

I'm pretty sure there used to be a page somewhere to ask for SQL queries to be run. I did a cold search, and found Wikipedia:SQL requests, which led me on this amazing journey, via a 6-way soft redirect-cum-splashpage-cum-suggested page runaround:

• Wikipedia:SQL requests → meta:Requests for queries → wikitech:Nova Resource:Tools/Tools/Query service → wikitech:Obsolete:Tool:Query service → Jira DBQ → wikitech:Portal:Toolforge →?→ wikitech:Category:Toolforge_tools

but never found my answer. So my first question is, where should Wikipedia:SQL requests *really* [soft-]redirect to?

Secondly, if you happen to know SQL and your appointment tomorrow with the Prime Minister was canceled at the last minute, I'm looking for two queries, yielding a count, and a handful of sample pages:

• count – how many non-existent pages in Draft space have one or more in-links from mainspace? (I.e., if Draft:Foo_123 has one in-link from mainspace, Draft:Bar_456 has five, and Draft:Baz_678 has one hundred, the total count is 3.)
• sample – can I get a list of around a dozen non-existent PAGENAMEs in Draftspace from that set, somewhat randomly selected (i.e., not all starting with 'A').

Thanks! Mathglot (talk) 03:18, 25 October 2021 (UTC)

WP:Request a query. – SD0001 (talk) 03:29, 25 October 2021 (UTC)

@SD0001:, thank you! Mathglot (talk) 05:31, 25 October 2021 (UTC)

Moved to WP:Request a query § Non-existent Draft PAGENAMEs with in-links from mainspace

20:06, 25 October 2021 (UTC)

Recently completed the Compiler page in the Oberon tutorial. I expect higher level headings to be more prominent than lower level headings. For example, "Tutorial objective" and "Introduction" (level 2) should be more prominent than the subsection "A first example" (level 3). In appearance, prominence is reversed. Levels 2 and 3 headings are rendered in a similar font size but level 3 is bold. Can anyone explain? A bug in MediaWiki? Can it be corrected? Thx, ... PeterEasthope (talk) 14:35, 21 October 2021 (UTC)

@PeterEasthope: As far as I can tell, everything looks as intended in Vector, Monobook, and Timeless. Judging from your description, you're using Monobook, which is the only skin of the three that has bold h3s and regular h2s with the same font. If you just want to swap the font weight of the two (on your end only), you can add the following to your monobook.css on Wikibooks:

h2 {
  font-weight: bold;
}
h3 {
  font-weight: normal;
}

– Rummskartoffel 15:20, 21 October 2021 (UTC)

Skin has examples of the four skins. Can the skin be identified visually? Something more certain? In Monobook, the links in the left margin are framed. In Vector, the links are listed with no frames. Please have a look at the UEFA Euro 2012 Final page. In default Vector style I see level 2, "Route to the final" in plain face; level 3, "Spain" in bold face. Why is the subordinate heading more prominent than the superordinate heading? Thx, ... PeterEasthope (talk) 04:51, 22 October 2021 (UTC)

I disagree that the level 3 headings are more prominent in any of these four skins, though they do look too similar for my taste in Timeless. I don't know the exact design decisions that went into making the headings look the way they do, since I'm not a developer; for that, consider asking a member of the Web team. In any case, I'm not seeing a bug here. – Rummskartoffel 12:09, 22 October 2021 (UTC)

I disagree that the level 3 headings are more prominent in any of these four skins

To the best of my understanding, J. Doe with a default environment will see level 2 headings in plain face; level 3 in bold face; similar or same font size in both. Most people will agree that bold is more prominent than plain.... PeterEasthope (talk) 17:47, 22 October 2021 (UTC)

... consider asking a member of the Web team.

Will do, thanks.... PeterEasthope (talk) 17:47, 22 October 2021 (UTC)

I also find level 3 more prominent than level 2. I'm used to it now, but was initially confused as L2 seemed to be a subsection within L3. I use Legacy Vector (if I'd wanted a narrow screen, I'd have bought one) but standard Vector has similar headings. Certes (talk) 13:09, 22 October 2021 (UTC)

Me to. I use Monobook and H3s are bold and look more prominent which always seemed wrong. MB 16:00, 22 October 2021 (UTC)

C>I'm used to it now, but was initially confused as L2 seemed to be a subsection within L3.

We all accepted it for too long. Ref. The Emperor's New Clothes. Regards, ... PeterEasthope (talk) 17:47, 22 October 2021 (UTC)

I guess this is all a matter of subjective personal taste, but I, for one, see level 2 headings as clearly superior to the L3–L6s. After all, they're in a larger typeface and they have that great, big horizontal rule stretching all the way across the page. I think one of the Vector skins shows me no discernable difference between H5 and H6 (only), but in my usual skin, Monobook, all the levels are clearly and recognizably differently sized. — JohnFromPinckney (talk / edits) 22:00, 22 October 2021 (UTC)

It's certainly skin-dependent. I've checked out four properties (font-family, font-weight, border-bottom and font-size) for all six heading levels in four skins. Three properties are easily summarised:

• MonoBook uses a normal-weight sans-serif font for all heading levels
• Timeless uses a normal-weight serif font for all heading levels
• Vector and Minerva use a serif font for levels 1 and 2 only, but sans-serif for levels 3, 4, 5 and 6
• Vector and Minerva use bold for levels 3 and 4 only, normal weight for levels 1, 2, 5 and 6
• MonoBook, Timeless and Vector show bottom borders (n.b. not horizontal rules) for levels 1 and 2 only, none for levels 3 to 6 - Minerva does not use borders at all.

The fourth is best presented as a table:

The font-size: property

Level	MonoBook	Timeless	Vector	Minerva
h1	188%	2em	1.8em	1.7em
h2	150%	1.8em	1.5em	1.5em
h3	128%	1.6em	1.2em	1.2em
h4	116%	1.4em	100%	100%
h5	108%	1.25em
h6	100%	1.2em

The Vector results are the same for "old" and "new" variants. --Redrose64 🌹 (talk) 00:02, 23 October 2021 (UTC)

"Old" is post-mw:Typography refresh Vector, rather than "original" Vector. The last major update to Vector was in late 2013 and 2014. That was when the ==Level 2 section headings== started using a serif font. If memory serves, this decision was driven by research (e.g., what font is easiest for people to read on a computer screen) rather than someone's aesthetic view.

About making changes: The archives for this page will show many people complaining about it the day that it hit, some people still complaining a week or two later, and only one or two editors still unhappy with it a month or two later. Apparently we hate having the fonts changed, but we get used to the new appearance on approximately the same time schedule that every other major website has found. I would expect the same outcome if similar changes are made in the future. Partly because of remembering that experience, I've stuck with the default skin at sites that have adopted New Vector. I've encountered some hiccups along the way, and re-locating the search box has proven to be surprisingly difficult for me to adapt to (but maybe if all the wikis were the same, I'd have gotten used to it faster?), but it no longer seems foreign and bad, and I have found one clear advantage: I haven't ever accidentally clicked the "Log out" button in New Vector.

(Important note to anyone thinking about changing the fonts in the future: Please don't.) Whatamidoing (WMF) (talk) 16:00, 26 October 2021 (UTC)

Hi all - was pointed to come here with this question from the help desk. Currently, some articles that have an importance assessment are showing up as "NA", even though they have an importance scale assigned to them. I was wondering if there was a way to fix this? Wikipedia:WikiProject Anarchism Jamzze (talk) 20:05, 25 October 2021 (UTC)

Please link to one or two articles with this problem. – Jonesey95 (talk) 20:46, 25 October 2021 (UTC)

@Jamzze: And make sure they really are articles. I suspect the "articles" you have in mind are actually redirects but it's hard to tell without an example. Always include an example. PrimeHunter (talk) 11:54, 26 October 2021 (UTC)

Yup, looks like they're redirects that have their class set. I just fixed one of them. --rchard2scout (talk) 12:43, 26 October 2021 (UTC)

Hi all - thanks so much - I had no idea! Will have a look at the redirects and change that then. Jamzze (talk) 17:08, 26 October 2021 (UTC)

@Rchard2scout and Jamzze: Explicitly setting |class=redirect is rarely necessary, because most WikiProject banners will autodetect it; Milhist is a rare exception. Unless the page is an actual article or a disambiguation page, it's normally best to omit the |class= parameter, or leave it blank. --Redrose64 🌹 (talk) 20:26, 26 October 2021 (UTC)

On two occasions lately I have fat-fingered rollback. On both occasions a dialog box opened that asked me if I really wanted to do that. On both occasions I answered “Cancel”, but it performed the rollback anyway. I need to disable this for myself, as I don’t tend to use rollback and obviously the option is causing more harm than good, but I thought maybe a technical-minded person could look into it. Thank you! 78.26 _{(spin me / revolutions)} 02:57, 26 October 2021 (UTC)

@78.26: before diving in any further, would you please check Special:Preferences#mw-prefsection-gadgets and confirm if your option for Require confirmation before performing rollback on mobile devices is checked? — xaosflux ^Talk 17:07, 26 October 2021 (UTC)

@Xaosflux: Yes, it is, thank you for asking. And in fact, the confirmation is popping up just like it should. The problem is that when "Cancel" is selected, the rollback is performed anyway. 78.26 _{(spin me / revolutions)} 17:10, 26 October 2021 (UTC)

@78.26: thank you, can you provide an example of the last time this occurred? I suspected it might have been Special:AbuseFilter/examine/1436794383? Can you be a bit more specific about your interface? Are you using the mobile application (ios or android), or the mobile web? If using a mobile device and web, are you using "desktop view"? — xaosflux ^Talk 17:23, 26 October 2021 (UTC)

@78.26 Which browser, device, and skin are you using? — MusikAnimal ^talk 17:25, 26 October 2021 (UTC)

@Xaosflux:, @MusikAnimal:, the last two examples are: [3] and [4]. This is on an Apple iPhone 6s, Software Version 14.6., Safari browser, "desktop view" (sorry, I really don't like mobile view). Does that help? 78.26 _{(spin me / revolutions)} 17:35, 26 October 2021 (UTC)

@78.26: using that same browser, would you mind sharing your useragent? You can fetch that from sites such as Google using this link. Feel free to redact any version numbers in there. — xaosflux ^Talk 17:52, 26 October 2021 (UTC)

Just a note, this is MediaWiki:Gadget-confirmationRollback-mobile.js. — xaosflux ^Talk 17:56, 26 October 2021 (UTC)

Mozilla/5.0 (iPhone; CPU iPhone OS 14_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko). 78.26 _{(spin me / revolutions)} 18:04, 26 October 2021 (UTC)

@78.26 Thanks. I unfortunately have no way of testing the behaviour on an iPhone, but I do recall someone reporting this same issue before and they were also using an iPhone. Could you try using a different browser, such as Chrome or Firefox? That will at least narrow it down to a Safari issue. The gadget itself is extremely simple and should in theory work in virtually all browsers. — MusikAnimal ^talk 20:50, 26 October 2021 (UTC)

Allright, I'll make some test edits with my alternate account and then try to "not-rollback" on both the Safari browser and Chrome. (I've never used Chrome on my mobile device, guess I'll see how I like it...) I'll ping you with the result. 78.26 _{(spin me / revolutions)} 20:56, 26 October 2021 (UTC)

@MusikAnimal: I presume this is bad news, but on both browsers (Safari, Chrome, both using Desktop view) I hit "rollback" and selected "Cancel" each time. I never selected "OK" on either browser. If you check my edit history you'll see the discouraging results. 78.26 _{(spin me / revolutions)} 21:14, 26 October 2021 (UTC)

@78.26: Yes, bad news :( That must mean it's an iPhone issue, I suppose. I will try to find a device (or virtual device) to debug this further. For now, since you say you rarely use rollback, you could hide the links entirely with User:MusikAnimal/rollbackTouch.js. — MusikAnimal ^talk 21:34, 26 October 2021 (UTC)

@MusikAnimal:Thanks! My next question was going to be if I could disable this (you can't in Preferences, already looked) because I can think of twice I've used rollback on purpose. Thank you also, Xaosflux. 78.26 _{(spin me / revolutions)} 21:38, 26 October 2021 (UTC)

If you never use rollback on desktop either, you can simply hide them by adding

.mw-rollback-link {
	display: none;
}

to your common.css. That would be simpler and faster than installing that script or enabling the gadget. Nardog (talk) 21:53, 26 October 2021 (UTC)

Yeah, I was going to suggest that, but it leaves a lingering pipe character next to "undo". In order to remove that you need to remove the outer span which doesn't have a CSS class or ID. We could hide the first span under .mw-changeslist-links, but I'm not sure that accounts for rollback links in all places, or if there are cases where rollback isn't in the first span. Finally, the script only targets mobile devices (though 78.26 made it clear they don't use rollback on any device). But anyway, yes, a CSS-only solution is always more efficient. — MusikAnimal ^talk 22:22, 26 October 2021 (UTC)

That's only true on history. On Contributions, Watchlist and RecentChanges the whole list item gets removed. It also has the problem of not taking effect after a live update. Nardog (talk) 22:27, 26 October 2021 (UTC)

Bah! Okay I've removed the .parent() (which I only added just before I commented here). A pity that the HTML isn't consistent across change lists. Thanks for pointing that out! I can do the special handling for history pages, I suppose.

Good point also about live update. This script I believe predates the live feature of Watchlist and RecentChanges, though of course other scripts/gadgets could dynamically add rollback links as well. I'll fix that, but for anyone reading this who wants to hide rollback links forever and always, like 78.26, use the CSS Nardog mentioned above :) I assume for most people the stray pipe characters on history pages is not much of a nuisance. — MusikAnimal ^talk 22:38, 26 October 2021 (UTC)

It would be simpler if you just added a class to <body> if the user agent indicates a mobile device and hid rollback links under that class in CSS. Nardog (talk) 22:51, 26 October 2021 (UTC)

@Nardog Clever! That's a pure JS solution (assuming you'll use mw.util.addCSS(), so there's still a bit of delay as opposed to pure CSS, but that seems more than acceptable here. I'll give this a go when I find the time. If you wanted to write something yourself I'll happily review it and merge it into the gadget. Just ping me :) — MusikAnimal ^talk 05:38, 27 October 2021 (UTC)

It's really weird that the rollback gets performed despite choosing Cancel, as opposed to the gadget not taking effect at all. I can totally see the gadget failing when used on Ajax-updated pages though, since it's attaching the handler to .mw-rollback-link just once, directly. I think it should either make use of event delegation as in $(document.body).on('click', '.mw-rollback-link', function (e) {... or hook it to wikipage.content and attach the handler every time the page is updated.

$(".mw-rollback-link").parent().remove() removes not just the links but the whole list items with them (i.e. .parent() is unnecessary). But I don't understand why you wouldn't just hide them in CSS. Nardog (talk) 21:53, 26 October 2021 (UTC)

Only after this lengthy discussion did I recall meta:WMDE Technical Wishes/Rollback which has been around for a while now. In Preferences > Appearance, look for "Show a confirmation prompt when clicking on a rollback link". This makes it work much like the "Thank" button which requires a second click to confirm. However there appears to be some UI issues in the Advanced Mode on mobile. But for those who only work off of the desktop UI (be it on a mobile device or otherwise), this is a nice solution to the problem. — MusikAnimal ^talk 05:47, 27 October 2021 (UTC)

@MusikAnimal: sorta - that will also force the link when not "on mobile" too. — xaosflux ^Talk 12:30, 27 October 2021 (UTC)

Hello! We wanted to make a gentle reminder that, since last May, there is a new default way to search files and other media on Commons. Special:MediaSearch has been developed in the past year to make use of the structured data on Commons and information from Wikidata in order to provide users with more relevant and extensive results, regardless of the language used for the query.

The new interface allows users to access some of the file information (licensing, description…) directly on the page, gives users various options to better filter results, and relies on Wikidata's concept-linking abilities and multilingual labels. Special:Search remains available for users for cases when its purposeful wikitext-based search may be more appropriate to use.

MediaSearch is just one part of the larger Structured Data Across Wikimedia project, which aims to structure content on wikitext pages, to make reading, editing, and searching easier and more accessible across projects and on the Internet. If you want to learn more about the project, please visit the project pages on MediaWiki, subscribe to the SDAW Newsletter, or get in touch with us on the project's talk page. The Structured Data team looks forward to continuing work on opening up Wikimedia content. Thanks! -- Sannita (WMF) (talk) 13:58, 27 October 2021 (UTC)

Sorry, I'm not sure if this is the right place for this message but here goes. The VisualEditor is a more accesible way of editing and I really think we should make as many of our pages work with it as is possible. I have come across various templates such as List of listed buildings in Stonehaven, Aberdeenshire, aviation destination lists on airport pages, and multi-column templates, that make it harder or impossible to edit and add references using the VisualEditor. In frustration, I created a deletion discussion at Wikipedia:Templates_for_discussion/Log/2021_July_11#Template:Airport_destination_list but it was kept, and to be honest I felt the keep arguments were unconvincing.

I suppose I want to see if anyone has the same feelings as me here, and if an argument could be made for removing these templates on the grounds of their negative impact on accessibility. Especially in the case of templates creating tables, I just don't think it's beneficial as experienced editors still know how to edit table syntax in the source code editor, but new editors or those who find the VisualEditor easier to use are locked out from editing. Could multiple columns be created using a div and CSS, avoiding the need for a template? If we want new editors to cite their sources, we need to make it easy for them to do so. NemesisAT (talk) 11:39, 26 October 2021 (UTC)

I don't use VE, but doesn't ((Airport destination list))'s documentation need a TemplateData section in order to make it usable with VE? I thought that was required, or at least required for ease of use. ((HS listed building row)), which is used in the list article, is also lacking TemplateData code. – Jonesey95 (talk) 16:11, 26 October 2021 (UTC)

I'm unable to experiment with TemplateData on ((Airport destination list)) as it has been locked, however my gripe with it was that you can't add citations, or indeed any formatting, unless you know the wikicode off-by-heart at which point you may as well use the source editor anyway. In fact, I believe it is not possible to add a citation or use WYSIWYG editing for any template paramter within the VisualEditor. Regarding the listed buildings template, that article is actually one template containing many more within it. It appears to be too much for the VisualEditor to load but again even if it did load, as the entire article is located within template parameters it is impossible to use VisualEditor tools to edit it, you're stuck with using source code within the VisualEditor. Hopefully this makes sense! TemplateData is good but I don't think it would resolve the issues I'm facing here. NemesisAT (talk) 16:20, 26 October 2021 (UTC)

Somewhat perversely, TemplateData code is stored in the templates' documentation pages, which are not protected, so you should be able to add it yourself, to each of the templates in question. I don't think it makes sense to assume that the templates would not work with VE if they were properly equipped with TemplateData code; try it first before giving up. For help in adding that code, your best bet is probably Wikipedia:Help desk. – Jonesey95 (talk) 16:37, 26 October 2021 (UTC)

Ah of course, I forgot that it's on the documentation page. I'll have a look. NemesisAT (talk) 16:57, 26 October 2021 (UTC)

I have started a TemplateData for ((Airport destination list)), but it will never be able to help you with adding a reference as the reference tools are all in the main VisualEditor toolbar, whereas the parameters of a template can only be edited in plain text. I should note that I am able to use the source code editor, in fact, I used to be opposed to the VisualEditor (both on here and on Wikia), but as it has developed, I've realised it is much easier for editing large tables and long pages with lots of references in them. NemesisAT (talk) 17:49, 26 October 2021 (UTC)

Three thoughts:

• @Johanna Strodt (WMDE) will want to see this, since WMDE is currently working on how to edit templates in the visual editor.
• Most table-oriented templates were created a long time ago. MediaWiki originally used plain old HTML to create tables (a pair of <tr> tags for each row, a pair of <td> tags for each cell, etc.) The creation of a wikitext syntax (|-for a new row, || to separate cells on the same line) for made it easier, but it's still hard, especially when the table is large, or if you want any colors or other fancy formatting. Editors created table templates because it was easier than the wikitext for large or heavily formatted tables. However, now that the visual editor handles all of "code" parts for you, it is generally easier to edit tables in the visual editor than to wrangle templates (unless you want colored text). I particularly recommend the visual editor to anyone who needs to add, remove, or rearrange the columns in an existing table.
• You can add and edit templates even if a TemplateData section doesn't exist. It's just (usually) more difficult.

Whatamidoing (WMF) (talk) 16:51, 26 October 2021 (UTC)

That's interesting, I didn't know about the history of the table syntax. NemesisAT (talk) 17:51, 26 October 2021 (UTC)

The specific WMDE link is meta:WMDE Technical Wishes/VisualEditor template dialog improvements. ((u|Sdkb)) ^talk 17:42, 27 October 2021 (UTC)

Late to the party but... sending a template to TfD on the grounds that it's difficult to edit in VE could be seen as WP:POINTy. --Redrose64 🌹 (talk) 20:17, 26 October 2021 (UTC)

Here are some scatter brain thoughts (without reviewing that TFD):

1. Templates can ensure intra-article consistency. While that is not something we necessarily need to preserve, it can be a nice benefit of table templates.
2. Templates can indicate the good 'default' information to include. (A drawback is sometimes that's an infobox with 50 parameters. ;)
3. Templates can restrict what is included, e.g. as in fan-driven wiki articles.
4. They are easier even than wiki syntax to deal with by experienced editors. Just because we know how doesn't mean we prefer to know.

They have detracting points too of course.

1. VE dislikes them. (BTW the Phab task you are looking for is phab:T52182 and related. It's old.)
2. Do we really need standardization across all such articles for all such tables?

I know in the past that some of table templates have been deleted as being generally unnecessary, but certainly not all. And those have mostly been table-start, table-row, table-end type templates, not templates that compose the entire construct.

Another Phab task of interest might be phab:T54582 for the specific template.

A specific point: Could multiple columns be created using a div and CSS Yes, but we don't want users to do that. It's fundamentally gross and requires inline CSS. In the case of reference blocks, one might consider advocating to remove ((reflist)) in the general case in lieu of <references/> since most people probably don't need what it provides anymore (columns of references), and where they do they could instead use ((div col)), which wouldn't make VE sad. Making general columns like ((col-begin)) does is somewhere on my to do list, but I don't know when I'll get to a nice version. Izno (talk) 17:00, 27 October 2021 (UTC)

In one discussion somewhere I saw a graph of active editors in English Wikipedia compared to those of French Wikipedia. I think the graphs were a screenshot of one of the autogenerated statistics pages. Anyone know what that page might have been and could you provide a link? Regards, A Thousand Words (talk) 06:07, 28 October 2021 (UTC)

I have no idea about that (I don't remember seeing any graphs), but at List of Wikipedias#Editions overview the table there has similar information for the more-or-less current moment. No idea if that satisfies your requirements. — JohnFromPinckney (talk / edits) 08:15, 28 October 2021 (UTC)

@1Kwords: Special:ActiveUsers gives a list of all the editors who have performed an edit on the English Wikipedia in the last 30 days, you can retrieve the number of active users using the ((NUMBEROFACTIVEUSERS)) magic word. Numbers for all projects are availiable on meta at meta:List of Wikipedias. 163.1.15.238 (talk) 12:23, 28 October 2021 (UTC)

The magicword only works on the local wiki, for any wiki: ((NUMBEROF|users|fr)) = 4845266 or ((NUMBEROF|activeusers|fr)) = 17334 -- GreenC 12:31, 28 October 2021 (UTC)

Found this page with Statistics, it shows number of active users over the last 12 months. The average is also shown, about 40K users for that time period. Found it via some searching and clicking the right links. A Thousand Words (talk) 19:24, 28 October 2021 (UTC)

Campus map, showing the partial workaround for the boundary disappearance

Campus map, showing the boundary disappearance bug

Following up from here, I'm continuing to have two issues with the Mapframe at Pomona College#Campus. The first (this thread) is that the boundary line has disappeared. The odd thing here is that it worked fine for a day or so when I first added it, but then it disappeared without any edits to the article/Wikidata item/OSM item I'm aware of, and it hasn't come back. The bug is replicated above at center.

The partial workaround I've found is to change |type=line to |type=shape, as shown above at right. However, even with the fill opacity set to zero, it still means anywhere in the interior of the campus becomes clickable with the title popping up. I'd much prefer it to return to the behavior from the line type before starting the FAC; does anyone know how to get that working again? Cheers, ((u|Sdkb)) ^talk 19:15, 23 October 2021 (UTC)

It's hard to say, but generally, I don't think shapes are supposed to be available in the line service. I'd be surprised if they were. Then again, our change in the osmdb sync has brought to light multiple changes already, so maybe there is an error. I really can't say. —TheDJ (talk • contribs) 12:54, 25 October 2021 (UTC)

@TheDJ, the OSM feature from which the boundary is (I think) being derived is way 458898308, which is a line rather than a shape. I know some other institutions have a relation in addition to a way; I don't really understand what the difference is between those or if that might be related to the issue. Also, I'm not sure what you're referring to with "osmdb sync". ((u|Sdkb)) ^talk 18:57, 25 October 2021 (UTC)

@TheDJ, okay, so I found phab:T285668. I'm still not quite sure what to do about this, though. Just drawing a line on the boundary rather than an infilled shape (using "service": "geoline" rather than "service": "geoshape") seems like something that ought to be possible, and it was possible until a week or so ago but now it seems it's not. ((u|Sdkb)) ^talk 20:42, 28 October 2021 (UTC)

That's not related, that ticket is about the toolforge OSM maps, which are way more broken than wikimedia maps at this point. There isn't a ticket about this particular issue yet, but i suspect it has something to do with the new way the import/update of the OSM database is being handled now. —TheDJ (talk • contribs) 20:51, 28 October 2021 (UTC)

Okay, thanks for the info; I created a phab ticket at phab:T294598. Cheers, ((u|Sdkb)) ^talk 21:08, 28 October 2021 (UTC)

I haven't lately checked - or unchecked - anything different on my Watchlist preferences. But my Watchlist is starting to show me the logs of Admin users. ANI suggested I uncheck the "logged actions" box. I don't see such a box, either on my Watchlist page, or on my Preferences. And it doesn't seem to be all admin logs that are showing up. Just two or three a day. Today's says "09:57 (Deletion log)‎ [Kusma‎; Favonian‎; Blablubbs‎]". And that's how it seems everyday. How do I stop this? — Maile (talk) 15:37, 29 October 2021 (UTC)

@Maile66: as far as I know, that happens when a page on your watchlist is deleted. At the top of your watchlist, there should be a box that says "Active filters". If it's hidden, click the "show" button. Then you can click the X next to "Logged actions" to stop showing them in your watchlist. I think that only lasts as long as you stay on the current watchlist page, but there's a bookmark icon to the right that allows you to save your filter preferences (mw:Help:New filters for edit review/Filtering). clpo13_(talk) 15:55, 29 October 2021 (UTC)

Something is missing here. "Active filters" is not on mine, but I can click on "Show", but the drop down does not give me the option of "Logged actions". — Maile (talk) 16:10, 29 October 2021 (UTC)

Do you have the "Use non-JavaScript interface" option checked in your watchlist preferences? That would show the old watchlist options, which doesn't include the newer, advanced filters. clpo13_(talk) 16:26, 29 October 2021 (UTC)

Aaahhhhhhhh ... I unchecked it, and the problem went away. Thanks. — Maile (talk) 16:33, 29 October 2021 (UTC)

See MediaWiki talk:Common.css § Orange bar of doom now peach bar of doom. Suffusion of Yellow (talk) 00:31, 30 October 2021 (UTC)

Scenario: 10k articles use the same infobox template. That template has code that hasn't been changed for 10 years (consider it deprecated). New template is ready. What are some advices and tips for the best workflow which causes the less amount of chaos with articles? Asking for cases outside of EnWiki. - Klein Muçi (talk) 23:57, 21 October 2021 (UTC)

Tell us more about the changes. Are there incompatible parameters? Whatamidoing (WMF) (talk) 00:38, 22 October 2021 (UTC)

@Whatamidoing (WMF), at most cases, no. But let's assume I have around 10 infoboxes suffering from the same problem and some of they may have totally new code syntax, for example having changed from traditional wiki text to Lua module invocations.

Real situation: Admin at SqWiki. Some infoboxes are outdated, we want to update them mirroring EnWiki. It's been month we've postponed that because we're worried about the chaos that my continue from that. Today I finally got the courage and updated the infobox related to musical artists, which was transcluded in +700 articles. The number of parameters and their type was more or less the same but in English so what I did was import the EnWiki version in a temporary name in SqWiki, get all the articles that it was transcluded on, feed that list on AWB together with 10 find and replace regex-es which would change the parameters on them (just translate them on English basically) and let my robot take over. Removed the old template, move the new one to the old name. Voila!

I was wondering if there are any other better ways I'm missing out on. - Klein Muçi (talk) 00:50, 22 October 2021 (UTC)

I think – and someone should please correct me if I'm wrong – that all of the good solutions inspire editors to improve the article on Vaporware, and that your current appropach is the most typical, and best, of the existing (poor) options. Whatamidoing (WMF) (talk) 16:12, 26 October 2021 (UTC)

@Whatamidoing (WMF), thanks for the answer. I was thinking I never got an answer back in this post. Good to know I'm on the right track. :) - Klein Muçi (talk) 23:18, 30 October 2021 (UTC)

Another potential option, for future use, would be to make the old template a wrapper for the new template. This ensures compatibility with the new parameters (and means you don't miss anything). Once this is done, you create a subst-only version of the old template, which then can be subst'ed away and replaced by the new template. Primefac (talk) 07:57, 31 October 2021 (UTC) (please ping on reply)

Rehelim is in both Category:Short description matches Wikidata and Category:Short description is different from Wikidata. Any explanation? Abductive (reasoning) 23:14, 29 October 2021 (UTC)

There is no such thing as contradicting categories from a category system point of view... — xaosflux ^Talk 23:19, 29 October 2021 (UTC)

((short description|Israeli settlement in the West Bank)) matches Wikidata but the infobox automatically adds the different short description "Place in Judea and Samaria Area". The first short description is used. PrimeHunter (talk) 23:27, 29 October 2021 (UTC)

(edit conflict) In short - there are 2 templates that are pushing those categories, ((short description)) and ((Infobox Israel village)) - that later of which requires more patience than I have right now to unravel. — xaosflux ^Talk 23:28, 29 October 2021 (UTC)

This is a perennial topic at WT:Short description. Brilliant solutions are welcome. – Jonesey95 (talk) 23:56, 29 October 2021 (UTC)

At the very least, update the documentation for Template:Infobox Israel village to let editors know what it is they are invoking when they use it? — xaosflux ^Talk 00:04, 30 October 2021 (UTC)

 Done. Never let anyone say I didn't do the very least. – Jonesey95 (talk) 16:31, 31 October 2021 (UTC)

I am seeking advice regarding ((EB1911 poster)). Currently the template does not function as described in the templat's documentation nor at Category:Wikipedia articles incorporating the template EB1911 poster with no parameters where it reluctantly states that failing to designate the article's title using the first unnamed parameter defaults to using ((PAGENAME)) albeit advisable to avoid. Currently, no such link is produced by such default although I have worked up a functioning solution in the templat's sandbox. Yet, because the template is protected, and I don't wish to use the TE flag inappropriately, I ask: would it be better for me to rewrite the instructions to correspond with the templat's functionality, or recode the template to correspond with the instructions? Additionally, the category's title makes it seem that the template was used without any parameters being used when in fact it only red flags and categorizes based on whether or not (({1|))} is used (even when other parameters are used). In this case I ask: should the category be moved to a more accurate title (like Category:Wikipedia articles incorporating the template EB1911 poster without designating the article's title for example) or here again, simply rewrite the instructions to accurately describe what triggers the categorization of member pages? Thank you for considering this request, and for any advice given. I appreciate the opportunity to learn from those regularly watching this page.--John Cline (talk) 10:19, 1 November 2021 (UTC)

Shouldn't these questions be asked at Template talk:EB1911 poster. Doesn't seem like an appropriate topic for WP:VPT.

—Trappist the monk (talk) 11:37, 1 November 2021 (UTC)

Thank you for your reply. I'll move the thread to that page. --John Cline (talk) 12:28, 1 November 2021 (UTC)

@John Cline: Yet, because the template is protected, and I don't wish to use the TE flag inappropriately... Template editor was granted to you because you are trusted to perform changes to pages protected so. Unless you have a COI of some sort (which it's hard to think would be applicable to a 110-year-old revision of Britannica), do what you think is best for the Wikipedia. Izno (talk) 12:35, 1 November 2021 (UTC)

Thank you Izno, I appreciate your reply. I've already moved the discussion to Template talk:EB1911 poster#Advice regarding an update of this template so I'll leave it open for a little while and mark this thread as resolved. Thanks again.--John Cline (talk) 13:03, 1 November 2021 (UTC)

Resolved

Compare the mobile view and desktop view of an old version Wikipedia:Wikipedia Signpost/2021-10-31/Book review. For some reason, using a colon for indentation in the first para after the Signpost templates shows a large blank area in mobile view. I replaced the colon with <div style="margin-left:1em;"> which displays properly in mobile web. I have occassionally seen this type of bug in talk pages too. Any idea what's the reason behind this? ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 14:33, 1 November 2021 (UTC)

A colon is not for indentation. This is a bad habit we developed on talk pages, but generally a colon is part of a definition list. We generally use the template ((hatnote)) or any of it's more specific children templates for styling this. —TheDJ (talk • contribs) 15:11, 1 November 2021 (UTC)

The content there would probably better use ((block indent)). --Izno (talk) 15:20, 1 November 2021 (UTC)

As a way to fight persistent creation of new socks on a /16 IP range with lots of legitimate traffic, I'm thinking the best tool might be to partial-block the /16 from some rarely-used namespace (say, "Gadget Definition Talk") and also tick the "Block account creation" box. I think that would have the effect of letting everybody, including IPs, continue to edit, yet prevent new socks from being generated. I assume that would work? Any reason not to do something like that? -- RoySmith (talk) 15:55, 31 October 2021 (UTC)

That's cute. I would use a namespace that most people can't edit such as Gadget or MediaWiki, not a talk namespace, leaning to MediaWiki because that one is guaranteed not to go anywhere. If I were to do something like this. And if it works. Izno (talk) 16:40, 31 October 2021 (UTC)

@RoySmith and Izno: you don't need that hack, you can just do what you want to do - see example at testwiki:Special:Redirect/logid/266527. — xaosflux ^Talk 16:58, 31 October 2021 (UTC)

Interesting. Hey, could you give me a mop on testwiki so I can play with this? -- RoySmith (talk) 17:14, 31 October 2021 (UTC)

Oh, I see what you did. Select "Partial", leave "Pages" and "Namespaces" both blank, and tick "Block account creation"? I just assumed you had to put something into one of Pages or Namespaces, but I guess not? -- RoySmith (talk) 17:17, 31 October 2021 (UTC)

 Done and nope - not required to actually include any "editing" blockage. — xaosflux ^Talk 17:36, 31 October 2021 (UTC)

That's pretty cool. I'll keep that in mind if I ever need to only prevent account creation from a range. Dreamy Jazz ^{talk to me | my contributions} 18:17, 31 October 2021 (UTC)

This is a very neat trick! I wish I had known about this since partial blocks were introduced. I think this deserves documentation. For starters I've added a note at Wikipedia:Blocking IP addresses and Wikipedia:Partial blocks. — MusikAnimal ^talk 17:00, 1 November 2021 (UTC)

20:26, 1 November 2021 (UTC)

Prompted by WP:VPM#Very big pages, I took a look at 2021 in mammal paleontology. A big chunk of the load time is a pile of tiny png files of national flags, many of which are smaller than 200 bytes (i.e. the HTTP headers swamp the data). This seems like a perfect use for sprites. Does the mediawiki software support that in any way? -- RoySmith (talk) 15:35, 29 October 2021 (UTC)

No, that's not how the web works. That said, the fix is obvious: Remove the "pile of tiny png files of national flags". Izno (talk) 16:12, 29 October 2021 (UTC)

There are around 58 different flags. That's not so bad. Many articles have around 200. PrimeHunter (talk) 22:33, 29 October 2021 (UTC)

CSS image sprites is one approach to convert loading multiple little images into loading a single image. In theory, someone could make a template to encapsulate the inner workings away for something like a composite image of all the national flags. More investigation is needed to determine how much savings it might provide, and weigh it against the cost of maintaining a composite image. isaacl (talk) 05:17, 30 October 2021 (UTC)

@Isaacl: could be a possible solution when template size is exceeded on some list pages as well. — xaosflux ^Talk 12:10, 30 October 2021 (UTC)

This is doable with TemplateStyles, IIRC. We'd need to put together a standard sheet with all the flags that an article might use, though. (We couldn't practically have a separate sheet specifically for the flags used in a particular article, nor is there a system for generating them like that.) I don't know if this would make sense to do from a performance perspective. --Yair rand (talk) 17:47, 31 October 2021 (UTC)

The problem with sprites for something like this, is that it only really works well if the same images are used a lot on the same page. Having a sprite with 500 different flags while most pages only use one flag or 0 flags, doesn't really make sense either. This is where optimising for Wikipedia becomes really difficult. Our pages are just all so different that many common optimisation strategies don't apply. —TheDJ (talk • contribs) 10:24, 2 November 2021 (UTC)

Just a heads up: There's a bunch of toolforge-based services (and possibly others?) down right now. I'm told there's a network issue in the toolforge infrastructure that's to blame and it's being worked on. So if something's not working, that's probably why. RoySmith-Mobile (talk) 12:55, 2 November 2021 (UTC)

Latest update: "The incident has been resolved, all the alerts will start clearing up shortly. If you still see some issues, please ping us ... on IRC (#wikimedia-cloud on libera.chat)." -- RoySmith (talk) 14:15, 2 November 2021 (UTC)

A maintenance operation will be performed on Wednesday 3rd November 06:00 AM UTC. It should only last for a few minutes. During this time, publishing edits will not be possible at English Wikipedia.

For more details about the operation and on all impacted services, please check on Phabricator.

A banner will be displayed 30 minutes before the operation.

Please help your community to be aware of this maintenance operation. Thank you!

Trizek (WMF) (talk) 15:03, 2 November 2021 (UTC)

Hi! Can we all agree the software should only use the term revert to mean undoing somebody's edit to the previous state, you know like the word means? Currently it is possible to hit the undo button AND THEN MAKE ANY UNRELATED CHANGES, and the poor sob making the original change will see his changes "reverted". This is not a theoretical concern, I just got bitten by it. --Palosirkka (talk) 14:46, 31 October 2021 (UTC)

@Palosirkka: Could you explain what the issue is, because I'm not seeing the issue from that article's history. You fixed the logo size, but did so using the wrong syntax. Ahunt came along and fixed the syntax for you. You reverted his edit because ???, then Ahunt reverted your revert. The only diffs in that chain that are tagged as "undo" (i.e. having involved clicking the undo button) are your revert and Ahunt's revert of your revert. The only edits that are tagged as "reverted" Ahunt fixing the syntax and you removing Ahunt's fix. As far as I can see everything is correct? 192.76.8.77 (talk) 14:58, 31 October 2021 (UTC)

@192.76.8.77:The issue is Ahunt didnt revert my change returning the article to it's previous state but ALSO made other changes. Yet the software called it all misleadingly 'reverted'. Do you now see my point? I reverted precisely because of the word reverted was used without looking at the diff. This misleading lingo can lead to such silly reverts and even "edit wars". --Palosirkka (talk) 15:05, 31 October 2021 (UTC)

It's a partial reversion, or a "revert and do differently". However, the software does label any change made with the undo button a reversion, even if it keeps the previous edit intact and changes something unrelated. Please try not to take the "Reverted" tag personally. It doesn't necessarily mean your edit is being criticised. On this occasion, you spotted a problem and partially solved it, allowing another editor to stand on your shoulders and finish the job. Certes (talk) 15:12, 31 October 2021 (UTC)

And that should be changed. I don't take it personally at all but it causes unneccessary re-reverts. --Palosirkka (talk) 15:17, 31 October 2021 (UTC)

I reverted precisely because of the word reverted was used without looking at the diff. So you deliberately edit warred without reviewing the changes in the revision? That seems blockable. Maybe you shouldn't do that instead. Izno (talk) 15:13, 31 October 2021 (UTC)

lol, no. I reverted Ahunt's edit because the software claimed he had removed my useful change. --Palosirkka (talk) 15:17, 31 October 2021 (UTC)

I think your point is clear, but unfortunately, things aren't so simple in our world (and the "Undid revision 1052844..." text that appears in the edit summary field with "undo" is only a suggestion; editors are free to adapt that text as appropriate). In the world in which we're working, edit summaries are very often incomplete, misleading or missing altogether. It behooves us all to actually check the diffs we undo/revert/rollback; after all, we take responsibility for each and every edit we make based on content even more than ES or "Reverted" flags. I hope you can consider this one of those "lessons learned" and continue contributing to Wikipedia with this knowledge helping you. Technically, I think it'd be very hard to revise the system so that any edits before saving an "undone" edit negate the application of the "Reverted" marker in th histories. — JohnFromPinckney (talk / edits) 15:32, 31 October 2021 (UTC)

Technically, I think it'd be very hard to revise the system so that any edits before saving an "undone" edit negate the application of the "Reverted" marker in th histories. No that's already been done (phab:T259014). Nardog (talk) 15:35, 31 October 2021 (UTC)

@Palosirkka: No he didn't - It's tagged as "reverted" because you reverted it - edits which are performing a revert are tagged "undo" or "manual revert" depending upon how you do them. The first edit he made to the page [6] is not a revert in any sense of the word - he just moved the 90px into it's correct section of the infobox. It was not performed using the undo button, it is not a manual revert and the software did not tag it as such. 192.76.8.77 (talk) 15:22, 31 October 2021 (UTC)

@192.76.8.77:Good catch! So, the example is wrong. Sorry for that folks... However I still think the undo button should only remove the edit in question without allowing other changes. --Palosirkka (talk) 15:31, 31 October 2021 (UTC)

Just a note, there was a similar discussion here last week, which generally seems to indicate that such actions are perfectly acceptable, though obviously if further changes are made they are indicated in the edit summary. Primefac (talk) 16:01, 31 October 2021 (UTC)

Just to chime in. I agree with the sentiment here. I also want to add that I think the word "revert" has gained a toxic overtone among the general public in relation to Wikipedia. I've seen people online complain "your edits get reverted by power users" countless times. That's probably because we overuse the term. It really should only be used for things like obvious vandalism. Good faith edits should not be "reverted" and a explanatory edit summary should be given. Jason Quinn (talk) 17:16, 2 November 2021 (UTC)

It seems that the image at the TITN is breaking the format of the whole page. Purging does nothing, but zooming until the TITN text is taller than the picture does display the page as it should be. - 49.147.242.233 (talk) 09:24, 3 November 2021 (UTC)

Portal:Current events/Headlines/styles.css was fixed to correct for this error. - 49.147.242.233 (talk) 12:17, 3 November 2021 (UTC)

Some diff-related user scripts may have been broken by https://phabricator.wikimedia.org/T285857, which modified the HTML structure of diffs. New CSS classes were added, and there may have been other changes too. Enterprisey (talk!) 06:32, 4 November 2021 (UTC)

Thanks for the heads-up. Based on the log, the changes AFAICS are:

• <td>s (including headers) now have a diff-side-deleted or diff-side-added class to indicate which pane.
• The markers (pluses and minuses) are now in the data-marker attribute, which is then shown in a pseudo-element.
• Empty lines now have <br> instead of a non-breaking space

Nardog (talk) 07:41, 4 November 2021 (UTC)

It's constantly switching between these two addresses. Why? --2A02:AA1:1625:94FC:19BF:E15A:695E:13F (talk) 14:41, 4 November 2021 (UTC)

Two weeks later there still is no WD link. WD link enables link to Wikidata item next to name at Wikipedia page. Why there is no information about this gadget or redirect to certain description in Wikipedia space or Wikidata item? Eurohunter (talk) 18:38, 3 November 2021 (UTC)

@Eurohunter: quickly going through the archives, it looks like you are trying to load a personal user script from wikidata, in to your personal global javascript - and are having some trouble with it? I suggest you start by contacting the user who's script you are loading at the project they host it in. — xaosflux ^Talk 18:46, 3 November 2021 (UTC)

@Xaosflux: No. I have it enabled in ENWP preferences (probably) and it worked here for some months or years until last month. What happened? Eurohunter (talk) 18:59, 3 November 2021 (UTC)

It just started working again foor no reason. Eurohunter (talk) 19:19, 3 November 2021 (UTC)

• No idea, Special:Preferences#mw-prefsection-gadgets / Special:Gadgets are the enwiki gadgets - what are you referring to in there? You do appear to have meta:User:Eurohunter/global.js set to load wikidata:User:Yair_rand/WikidataInfo.js - which describes itself as Add a small box under a Wikipedia article's title displaying the label, description, aliases and the identifier of the related Wikidata item. — xaosflux ^Talk 20:50, 3 November 2021 (UTC)
  • @Xaosflux: Yes but it was done there long time ago and only stopped working recently for weeks and it's working again. Why? Eurohunter (talk) 16:25, 4 November 2021 (UTC)

I already told you that at Wikipedia:Village pump (technical)/Archive 192#WD link: "d:User:Yair rand/WikidataInfo.js is loaded in meta:User:Eurohunter/global.js". Please read old answers and link old discussions when you report an issue. In the old discussion you said "it works elsewhere" but didn't give an example. Always include an example. PrimeHunter (talk) 21:19, 3 November 2021 (UTC)

@PrimeHunter: Yes but it was loaded there long time ago so why it didn't worked for 2 weeks? "it works elsewhere" - I mean every Wikipedia version expect ENWP so what I was supposed to say? I thought "elsewhere" is abvious and means every version expect ENWP. Right? Eurohunter (talk) 16:25, 4 November 2021 (UTC)

It could be lots of things, you could start by unloading all of these and only loading the one script - sometimes there are timing issues or other conflicts between javascripts. See also mw:Help:Locating broken scripts. — xaosflux ^Talk 17:00, 4 November 2021 (UTC)

I asked about Simple and you said "it still doesn't works in ENWP and SimpleWP and it works elsewhere". That claims it doesn't work in the only other place I asked about. Now you apparently claim it did work at Simple. Claims that something works or doesn't work everywhere are often false. There are 325 Wikipedias and around 600 other Wikimedia wikis where meta:User:Eurohunter/global.js is loaded. You obviously didn't test all of them. "elsewhere" includes Commons and so on. Even if the claim is right, readers don't know that and may spend significant time testing it at various places to see if any of them give or don't give the reported problem for themselves. Always give an example. ALWAYS. Helpers waste a huge amount of time on posts which don't give examples. You are also more likely to get fast and relevant answers when you give an example. Something in your personal JavaScript or gadgets may conflict with the script. Scripts are loaded in partially random order and the order may affect the result. If it fails again then try to log out, view an example page, and enter mw.loader.load('https://www.wikidata.org/w/index.php?title=User:Yair_rand/WikidataInfo.js&action=raw&ctype=text/javascript'); in the web console (Ctrl+Shift+K in Firefox on Windows). PrimeHunter (talk) 17:14, 4 November 2021 (UTC)

Campus map, showing the reference error bug

Following up from here, the second issue I've been having with the Mapframe at Pomona College#Campus (first in thread directly above) is that references don't display properly within the description field. Click on the pin at right to see how <ref>((cite news|last1=Fitz|first1=Allison|date=14 February 2020|title=New Rains Center to be completed by 2022; 5Cs prepare for construction's effects|work=[[The Student Life]]|url=https://tsl.news/new-rains-center-to-be-remodeled/|access-date=2 December 2020))</ref> gets mangled. The same thing happens with SFNs, which I'd also like to use. I haven't been able to make progress on this since last time, so it may require a phab ticket; if that's the case, I'm mostly looking to understand how to better present the issue to increase the likelihood it gets taken up. Thanks in advance for the help, ((u|Sdkb)) ^talk 19:15, 23 October 2021 (UTC)

Courtesy pinging those who commented previously: @Izno, Ɱ, TheDJ, Tgr (WMF), and Krinkle: see also the thread immediately above. ((u|Sdkb)) ^talk 19:15, 23 October 2021 (UTC)

@Sdkb T28213 is the general class this bug belongs to. Tgr (WMF) (talk) 01:04, 24 October 2021 (UTC)

This problem is because the templates used here just dump wikitext into geojson. But geojson doesn't support wikitext or html, geojson only supports text only descriptions. —TheDJ (talk • contribs) 13:05, 25 October 2021 (UTC)

The lua/template probably can use killMarkers to remove the references from the input. —TheDJ (talk • contribs) 13:10, 25 October 2021 (UTC)

I tried that, but mw.text.killMarkers and mw.text.unstrip don't seem to work any more (only mw.text.unstripNoWiki seems still functional). Is there any downside to removing the stripmarker with gsub? —  Jts1882 | talk  15:55, 25 October 2021 (UTC)

@TheDJ and Jts1882: Mapframe does seem able to handle images, so I think that means it's able to convert at least some types of wikitext into proper output. Would getting it to do the same with references be feasible, or is that out of the question? ((u|Sdkb)) ^talk 19:00, 25 October 2021 (UTC)

Campus map, showing the reference error bug

@Sdkb, Jts1882, and Tgr (WMF): I think I fixed it in the sandbox ? Markers include control characters and because control characters cannot be in json, these were getting stripped from the input. By moving that logic to later in the flow and using killMarkers on content explictely meant for the json body, I think we can work around both problems. —TheDJ (talk • contribs) 20:24, 25 October 2021 (UTC)

oh great, now the static map is broken again... Guess there is still a control char somewhere.... —TheDJ (talk • contribs) 20:29, 25 October 2021 (UTC)

ah interesting.. moved the coord a fraction and it fixed itself. I think i know why.. the livepreview saved a copy of the image with a different hash, causing an incorrect group reference being generated that the static tile renderer then cannot use... This likely happens a lot and I think i might already have a patch for that particular problem somewhere.

Campus map with mapframe tag directly

@TheDJ: I tried adding a ref within a direct call of mapframe HTML, as you suggested. It doesn't seem to have worked, though. Am I doing something wrong? ((u|Sdkb)) ^talk 23:34, 26 October 2021 (UTC)

@Sdkb: there were just a few errors in the json. Importantly, the json values need to be escaped (esp. "), but also geojson flips the order of the latitude and longitude (apparently that's a thing in Cartesian geometry). —TheDJ (talk • contribs) 08:21, 27 October 2021 (UTC)

Ref parameter

For anyone following along, after some discussion with TheDJ and others on Discord (around here), we'd like to add reference parameters (e.g. |ref2=, |ref3=) to Module:Mapframe. These would add <ref>reference content</ref> into the json appended to the end of the description parameter. This would bypass a parse cycle and make it so that the ref tag wouldn't be escaped when the JSON is made, resolving the bug. If anyone who knows Lua could help to code this, I would be grateful! ((u|Sdkb)) ^talk 07:55, 1 November 2021 (UTC)

Campus map, using a reference parameter

Bug when multiple features are used

@Sdkb: Does this edit do what you want (see right)? I was puzzled why it didn't work until I saw that the stripmarkers were being stripped out in recent changes. —  Jts1882 | talk  11:53, 1 November 2021 (UTC)

Jts1882, that looks fantastic; thanks so much! I did encounter a bug, though; it seems that if more than one feature is added, it goes back to displaying '"`UNIQ--ref-00000003-QINU`"' again. Any idea what's causing that? ((u|Sdkb)) ^talk 17:30, 1 November 2021 (UTC)

@Sdkb and TheDJ:Single features and multiple features are handled slightly differently. The latter are placed in an array and control characters stripped (in part of the code added to the sandbox by TheDJ to remove stripmarkers). I don't have access to your discussion on Discord, but am I right in thinking that these changes aren't needed with this reference solution. I've disabled the stripping of control characters (line 597) to show that the reference code otherwise works.

I think rather than removing stripmarkers in the code, it might be better to detect them and provide a warning or error message. If references it could suggest use of the reference parameters. —  Jts1882 | talk  08:18, 2 November 2021 (UTC)

I think there is a simpler solution. Escape the control characters on line 199 rather than replacing them with a blank.

Old:

cleanArgs[key] = (not util.matchesParam('text', key)) and val:gsub('%c',' ') or val

New:

cleanArgs[key] = (not util.matchesParam('text', key)) and val:gsub('(%c)','\%1') or val

Is there a problem with this? —  Jts1882 | talk  09:53, 2 November 2021 (UTC)

I guess that could work. let's try it. —TheDJ (talk • contribs) 10:17, 2 November 2021 (UTC)

@Jts1882, @TheDJ: The sandbox looks like it's working! Should we implement as is or do you want to try the simplification idea first? ((u|Sdkb)) ^talk 00:26, 3 November 2021 (UTC)

The current sandbox version makes a number of changes dealing with stripmarkers that might not be necessary. The simple solution of escaping stripmarkers might offer a more general solution and wouldn't be removing anything added to the template parameters. It worked for me in the tests I did in the editor. It's not clear to me why the control characters were replace by spaces rather than escaped before, as it seems to me this caused the stripmarkers to leak. If it works, then is the ref parameter needed? —  Jts1882 | talk  07:10, 4 November 2021 (UTC)

Oh, if it makes the ref parameter unnecessary, that's even better! I'm good with implementing the simplified version then. ((u|Sdkb)) ^talk 08:59, 4 November 2021 (UTC)

Version with multiple features using new sandbox solution (no reference parameter)

Not quite as simple as I thought. My solution above breaks json queries in |raw= parameters. I've reset the sandbox and added special handling for the description parameter using the above method, leaving handing of |raw= and other parameters unchanged. This works in the examples we've being using (see right or User:Jts1882/sandbox#mapframe_test) and doesn't break any of the ((Maplink/testcases)).

It was the replacement of control characters with spaces (to fix the issue of control characters in the json output) that cause the leak of stripmarkers. The |text= parameter was excluded from this process to protect stripmarkers, but stripmarkers in other parameters were corrupted. I'm not sure, but it seems that only the |raw= parameter needs special handling and that my fix could be used on the other parameters, which would allow references on titles as well. —  Jts1882 | talk  10:18, 4 November 2021 (UTC)

The technical part is over my head, but the behavior all looks good! I put a courtesy notice at the module talk page; if no one from there/here raises concerns, feel free to implement! ((u|Sdkb)) ^talk 19:26, 4 November 2021 (UTC)

I have created these eight pages, all redirects to Photoelasticity.

• Stress-optic coefficients
• Stress-optic coefficient
• Stress optic coefficients
• Stress optic coefficient
• Stress-Optic Coefficients
• Stress-Optic Coefficient
• Stress Optic Coefficients
• Stress Optic Coefficient

If someone comes along and changes one of them to a full-fledged article, then all of the others should redirect to that. But the creator may be unaware of those others. Is there some way we can use existing software to assure that that person will become aware of the situation? Michael Hardy (talk) 17:37, 4 November 2021 (UTC)

@Michael Hardy A comment? ― Qwerfjkltalk 20:58, 4 November 2021 (UTC)

In Wikipedia:Sockpuppet investigations/Ineedtostopforgetting/Archive, the "11 October 2021" L3 heading doesn't render. My first guess is something broken in the immediately preceeding ((SPIpriorcases)), but my eyes glaze over when I try to read that junk.

There is HTML being generated for it:

<h3><span class="mw-headline" id="11_October_2021" data-mw-comment="{"type":"heading","level":0,"id":"h-11_October_2021-Ineedtostopforgetting","replies":["h-Suspected_sockpuppets-11_October_2021-2021-10-11T01:46:00.000Z","h-Comments_by_other_users-11_October_2021-2021-10-11T17:27:00.000Z","h-Clerk,_CheckUser,_and\/or_patrolling_admin_comments-11_October_2021-2021-10-29T13:56:00.000Z"],"headingLevel":3,"placeholderHeading":false}"><span data-mw-comment-start="" id="h-11_October_2021-Ineedtostopforgetting"></span>11 October 2021<span data-mw-comment-end="h-11_October_2021-Ineedtostopforgetting"></span></span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Wikipedia:Sockpuppet_investigations/Ineedtostopforgetting/Archive&action=edit&section=1" title="Edit section: 11 October 2021">edit source</a><span class="mw-editsection-bracket">]</span> <span class="arky" style="display:none"><span class="mw-editsection-bracket">[</span><a data-header="3" data-section="1" onclick="$(this).closest(":header").toggleClass("arkyhighlight");$(this).toggleClass("arkylink");var archivable = $(".arky a"); for(var i=archivable.index(this); i<archivable.length; ++i) { if (archivable[i] == this) { continue; } if ($(archivable[i]).attr("data-header") > 3 && $(archivable[i]).hasClass("arkylink") != $(this).hasClass("arkylink")) { $(archivable[i]).click(); } else { break; } }">archive</a><span class="mw-editsection-bracket">]</span></span></span></h3>

but nothing actually displays. -- RoySmith (talk) 20:59, 1 November 2021 (UTC)

Perhaps the most efficient thing to do is ask User:Vanjagenije, who just (~3 days ago) archived part of the archive to another page, according to this. — JohnFromPinckney (talk / edits) 21:29, 1 November 2021 (UTC)

The box generated by ((SPIpriorcases)) has the "infobox" class, which is floating. Looks like it floats right on top of the heading; using the dev tools to manually set float: none on the box causes the heading to show up again. A naïve way to fix this would be to add that style rule to the template, which I've done in the sandbox (to see how it looks, edit the SPI page, replace ((SPIpriorcases)) with ((SPIpriorcases/sandbox)), and preview). Maybe there are better ways, though. – Rummskartoffel 21:40, 1 November 2021 (UTC)

(Don't use the infobox class for things that aren't infoboxes. This might better be using ((side box)).) Izno (talk) 22:28, 1 November 2021 (UTC)

@Firefly: you were the last person to edit ((SPIpriorcases)), but more importantly, you understand this stuff a lot better than I do. -- RoySmith (talk) 23:21, 1 November 2021 (UTC)

@RoySmith hmmm did I break something? I’m travelling at the moment but will have a look when I can get to a computer - assuming someone else doesn’t get there first :) firefly ( t · c ) 06:32, 2 November 2021 (UTC)

• I just removed the ((SPIpriorcases)) template [7]. It is not needed in the archive. Vanjagenije (talk) 16:12, 2 November 2021 (UTC)
• Can someone explain to me, in small words for slow minds, what the use case is for an element ever to be both float:right and width=100%? Isn't that just asking for breakage? —Cryptic 22:09, 4 November 2021 (UTC)

Today (and yesterday) every time I save or preview an article I get the message "Microsoft Edge not responding - waiting for intake-analytics,wikimedia.org. The resulting delay ranges from a few seconds to two or more minutes, making even a simple edit a time-wasting process. What is going on, and when will it be fixed? This problem does not occur in Safari on iPad. Downsize43 (talk) 01:18, 4 November 2021 (UTC)

That domain is for metrics measuring. It shouldn't take that long to respond and I haven't heard more complaints about it yet. If it keeps up however, please do open a ticket in Phabricator. They might ask you for some more details about where you are located and the ISP, because likely this is an internet routing issue and somewhat specific to the path between your ISP and wikimedia. —TheDJ (talk • contribs) 09:46, 4 November 2021 (UTC)

@TheDJ: I was having this problem just last month (c.f. Wikipedia:Village pump (technical)/Archive_192#slow_pages_saves_waiting_for_intake-analytics.wikimedia.org) - ended up just blocking this domain locally. — xaosflux ^Talk 17:03, 4 November 2021 (UTC)

@Xaosflux: Just how do I do that? Downsize43 (talk) 11:19, 5 November 2021 (UTC)

@Downsize43: I used a software firewall, there are many ways you could do this - but none of them are Wikipedia-specific. — xaosflux ^Talk 11:36, 5 November 2021 (UTC)

Hello! So I'm here to write about an issue (That's mostly minor) with my signature. If you look at my signature, you'll notice a gap between my talk link and my discord username, and the timestamp. Anyone know what part of the code causes this to happen and how I can fix it? ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 19:19, 4 November 2021 (UTC)

It happens because position:relative doesn't change the space reserved for the text. ((Sup sub)) uses another approach but templates are disallowed in signatures and Special:ExpandTemplates shows it uses a lot of code. PrimeHunter (talk) 02:08, 5 November 2021 (UTC)

You could try to use "margin-right:-22q" on the subscript style: Blaze The Wolf^Talk_{Blaze Wolf#6545} but I don't know if that would be exceed the character limit. --rchard2scout (talk) 12:06, 5 November 2021 (UTC)

Unfortunately it does. But thanks for trying. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 13:05, 5 November 2021 (UTC)

@Blaze The Wolf: try [[User:Blaze The Wolf|<b style="background:#0d1125;color:#51aeff;padding:1q;border-radius:5q;">Blaze The Wolf</b>]][[User talk:Blaze The Wolf|<sup>Talk</sup>]]<sub title="Discord Username" style="margin-left:-22q;">Blaze Wolf#6545</sub>. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 15:32, 5 November 2021 (UTC)

At ((Rotten Tomatoes prose)), I can't get parameters like |access-date= to work. I'm guessing this may have something to do with the bug about stuff not working within tags, but the normal workaround of using ((#tag|ref|content=the ref)) doesn't work either.:L Any idea what's happening/how to fix it? ((u|Sdkb)) ^talk 19:48, 5 November 2021 (UTC)

You have skipped a few steps. Here's some tough love:

1. Revert the recent non-working edits to the live template, which is transcluded on 131 pages, in case you broke anything.
2. Create a sandbox version of the template.
3. Create and populate a testcases page.
4. Use Special:ExpandTemplates to figure out what the rendered version of the template's wikitext looks like.
5. Modify the sandbox and testcases page until you fix the problem or have a better idea of where the problem resides.
6. If necessary, repeat the previous two steps until you fix the problem or get stuck.
7. If you fix the problem, copy the sandbox code to the live template.
8. Post a note on the template's talk page asking for help.

I'm happy to help if you get stuck, but please be more careful when editing templates. – Jonesey95 (talk) 23:01, 5 November 2021 (UTC)

@Jonesey95, I'll go create the sandbox. Regarding carefulness/the possibility of breaking anything, I wouldn't have proceeded if there had been a possibility of that. The reference parameters only appear when |ref=yes is set, and that's only done on one page, which I previewed before saving to ensure that nothing was broken. The access date not appearing on that one page until this issue is resolved isn't a crisis. I also sense that you have a feeling that I just came immediately to the pump before trying to resolve the issue myself. That's again not true—I spent a good 15 minutes tinkering with |ref=/similar to see if I could get it to work; just since I did it in preview rather than in a sandbox doesn't mean it didn't happen. ((u|Sdkb)) ^talk 23:08, 5 November 2021 (UTC)

@Sdkb: I've tried again with #tag: and it seems to work now. Certes (talk) 23:38, 5 November 2021 (UTC)

@Certes, looks good; much thanks! ((u|Sdkb)) ^talk 23:44, 5 November 2021 (UTC)

Hi techhies, I have two computers running Win 10 and the problem is only apparent on one of them (using Chrome), so not a bug at Wikipedia's end. Visual editor hangs up after loading 70% and never recovers. When editing in source mode, I have lost all the editing interface buttons (font size, italics, etc). Having already restarted a few times and ensured Java is updated, what is my next step for troubleshooting this? Loopy30 (talk) 19:57, 5 November 2021 (UTC)

@Loopy30: these don't require java - so it's not that. Try opening an "incognito" window in Chrome, don't even logon, and see if you can start editing that way (don't click publish). — xaosflux ^Talk 20:34, 5 November 2021 (UTC)

@Xaosflux: Yep, works fine in "incognito" mode, what would be the setting that is stopping me normally? Loopy30 (talk) 01:23, 6 November 2021 (UTC)

@Loopy30: I've turned off your userscripts (just revert my edit at User:Loopy30/common.js to turn them back on). Other things that could be related to your account, see if you have any beta features enabled and turn off. Then in your browser, clear your cache and cookies from wikipedia (you will have to log on again afterwords). — xaosflux ^Talk 01:29, 6 November 2021 (UTC)

Hello! I've enabled discussion tools, and they've been working fine for a while. Today, though, the reply link started to act weirdly. On some pages (but not all), the "reply" button looks wrong (like ^reply instead of [ reply ]). For example, this page looks fine, but my talk page has the superscript-like style. I've tried safemode (and clearing my common.js) to no avail. Does anybody know what's going on? Thanks. Tol (talk | contribs) @ 22:09, 5 November 2021 (UTC)

I cannot reproduce on your talk page. Please point to a specific thread and/or comment you are seeing the issue on. If this is an issue, it sounds like it is an issue with someone's signature having an unclosed <sub> element and not an actual problem with the system that generates reply links to me. Izno (talk) 01:13, 6 November 2021 (UTC)

Well, it's gone now. Weird. It was formatted differently with every comment on my talk (and on Wikipedia:Bot requests). I still have no idea what happened. Tol (talk | contribs) @ 03:33, 6 November 2021 (UTC)

I saw it too. Dug around a little and couldn't figure out what was up. All's well that ends well... Enterprisey (talk!) 04:25, 6 November 2021 (UTC)

I can't be sure but it might've been connected to the missing TOC issue (discussion above). I saw the wonky reply links on discussion pages when I was wondering where the TOC had gone. I made null edits on a few pages to get the TOC to appear and the reply links were probably OK too after that. (It was late at night so I'm not 100 % sure of what I saw.) kyykaarme (talk) 08:28, 6 November 2021 (UTC)

Is it possible to search archived versions of websites saved in Web Archive by content like in any web search? Eurohunter (talk) 18:28, 3 November 2021 (UTC)

@Eurohunter:

arquivo.pt has that feature, but it cover less pages than the archive.org. Still better than nothing. MarMi wiki (talk) 14:22, 6 November 2021 (UTC)

@MarMi wiki: Very interesting. It has more results than I expected unfortunatelly search tool is not optimised too well. Anyway I think Arquivo.pt should be listed somewhere as useful archive. Eurohunter (talk) 15:13, 6 November 2021 (UTC)

Book reference using SFNREF, website is not, but it's creating a targeting error. Darkwarriorblake / SEXY ACTION TALK PAGE! 16:19, 6 November 2021 (UTC)

If they are the same year then see Template:Sfn#More_than_one_work_in_a_year. A simpler fix is not to use the error-prone and reader-unfriendly sfn/harv system. DuncanHill (talk) 16:27, 6 November 2021 (UTC)

Thanks, that worked. Darkwarriorblake / SEXY ACTION TALK PAGE! 16:30, 6 November 2021 (UTC)

Using |ref=none on the cite web template should also work if it isn't going to be called by sfn/harv.Nigel Ish (talk) 16:39, 6 November 2021 (UTC)

Thank you, I knew I'd seen that before but I couldn't remember what the correct option was. Darkwarriorblake / SEXY ACTION TALK PAGE! 16:48, 6 November 2021 (UTC)

This search says that Wikipedia:Village pump (policy)/Archive 138 includes the phrase User:SMcCandlish is claiming the untrue once again, but it's not on the page. Digging into the wikitext source, it is in the wikitext, added in Special:Diff/814672137. Actually, a big chunk of the wikitext is missing from the rendered page, but I've been unable to isolate exactly where the missing chunk starts and ends. The W3C validator comes up with a bunch of nit-picky stuff, but nothing that looks like is should drop a big hunk of text. Can anybody see what's going on? -- RoySmith (talk) 18:51, 6 November 2021 (UTC)

The wikitext not too far north of that line has ((collapse top|title=Collapsing a dispute which has been mooted.)). --Izno (talk) 19:04, 6 November 2021 (UTC)

Ah, thanks! -- RoySmith (talk) 19:08, 6 November 2021 (UTC)

I just noticed that the table of contents was missing from Jacob Wohl, which has the requisite four headings that should autogenerate one. I've added __FORCETOC__ for now, but does anyone know what might've caused it? GorillaWarfare (she/her • talk) 21:50, 5 November 2021 (UTC)

Multiple users are experiencing this, it has been reported by three people at WP:HD, I'll direct them here. Beeblebrox (talk) 21:55, 5 November 2021 (UTC)

Huh, weird, I am experiencing this, but not consistently. I don't see a TOC at Jonestown or Alaska but do see one at Dune (2021 film) and History of Alaska. Weird. Beeblebrox (talk) 22:02, 5 November 2021 (UTC)

I see TOCs at all of those articles. I am using the legacy Vector skin. Check to see what skin the editors experiencing the problem are using. – Jonesey95 (talk) 23:06, 5 November 2021 (UTC)

Regular vector over here. GorillaWarfare (she/her • talk) 23:19, 5 November 2021 (UTC)

Oddly, the first time I looked at the Jonestown article there was no TOC. I made a change to fix the infobox, then I could see the TOC. Now, I see the TOC in all of the articles. I too use Real Vector — GhostInTheMachine ^{talk to me} 23:28, 5 November 2021 (UTC)

I am also using the legacy Vector skin, and I am also now seeing TOC on all four articles I mentioned above...so.... I dunno... Beeblebrox (talk) 01:16, 6 November 2021 (UTC)

In attempting to fix a different issue related to the ToC on language converter wikis (primarily Chinese), the revert ended up being worse and was un-reverted once the issue was realized. It should be fixed now, I added a link to the relevant Phab task. Legoktm (talk) 01:22, 6 November 2021 (UTC)

Wonderful, thank you for clearing this up! I've removed __FORCETOC__ from Jacob Wohl and the TOC is showing up as expected without it. GorillaWarfare (she/her • talk) 01:24, 6 November 2021 (UTC)

@Legoktm Awesome. It's back to normal for me too. -Oluwatalisman (talk) 02:22, 6 November 2021 (UTC)

"Contents" window having trouble

For some reason, the "Contents" index section on Wikipedia, which contains the heading section indexing, doesn't show up on a few pages for me (including for my talk page). I'm not sure why. Am I the only one? This has previously been discussed here.

EDIT: I just noticed a few people had already mentioned this issue above. WikiLinuz (talk) 23:20, 5 November 2021 (UTC)

The automatic generation of a contents list on talk-pages sees to kick in once a fourth section is added. Remove the fourth section and the contents list disappears. It's evidently part of the programming (whether or not it ought to be is another matter). See another example at Talk:Nero. Haploidavey (talk) 06:47, 6 November 2021 (UTC)

@Haploidavey: The TOC is automatically suppressed when there are fewer than four headings or subheadings (excluding the page title), by design. This is long-standing behaviour, and is mentioned at H:TOC. --Redrose64 🌹 (talk) 14:03, 6 November 2021 (UTC)

@Redrose64: Thanks for that, and for the notification. Very thoughtful of you! I'm sure the Notoc business is something I used to know. Or at least bits of it. But since I hit 70, I find these little biscuits of knowledge just fall into the cocoa of age, and are lost in a sludge of milky bedtime drinks. Haploidavey (talk) 14:20, 6 November 2021 (UTC)

@Haploidavey What???? -Oluwatalisman (talk) 18:56, 6 November 2021 (UTC)

@Talisman-white: Haploidavey has confused a long-standing feature (non-display of TOCs that would have three entries or fewer) with a recent bug (non-display of longer TOCs). --Redrose64 🌹 (talk) 21:47, 6 November 2021 (UTC)

When viewing old diffs, there are convenient "← Previous edit" and "Next edit →" links for navigation between the edits. When viewing the latest diff, only a "← Previous edit" link is shown for obvious reasons. However, if the page is edited again while you're viewing that diff, it'd be nice if a "Next edit →" link appeared so that that a) you'd know that another edit had been made without needing to view the watchlist/history again, and b) that newer diff could be viewed in one click. Is there a preference somewhere to achieve this? Sod25 (talk) 21:28, 5 November 2021 (UTC)

@Sod25 No, but you could ask at WP:SCRIPTREQ ― Qwerfjkltalk 21:35, 5 November 2021 (UTC)

This would require performance-degrading JavaScript for general use, but yes, a user script could maybe do something like this. Izno (talk) 01:10, 6 November 2021 (UTC)

What's the important feature here: having a "Next edit" link, or making it appear only when that next edit occurs? The former would be easy and efficient, as it only needs the current revision id (...&diff=next&oldid=current revision). If there is no next edit, it shows a "no changes" diff between the current version and itself. The costly bit, both for the browser and the (API?) server, would be polling for a new revision appearing. That might happen many times if the user leaves the tab open whilst doing something else. Certes (talk) 13:59, 6 November 2021 (UTC)

The polling could be done only if the tab is active. – SD0001 (talk) 14:51, 6 November 2021 (UTC)

Thanks for the replies everyone, I won't ask for a script to be custom written for me as this is a want not a need. An important part of the idea was the "Next edit →" link appearing so that you'd notice that another edit had been made, similar to how "↻ View new changes since..." appears in the watchlist for the same reason. The watchlist only seems to poll for new changes when you're viewing that tab, so that would probably be the way to go about it. Sod25 (talk) 22:51, 6 November 2021 (UTC)

align=center| or style="text-align: center;" ? If align=center| why without quotation marks if {| class="wikitable" has always quatation marks? <br /> or <br >? Eurohunter (talk) 10:05, 7 November 2021 (UTC)

style="text-align: center;" is preferable. align="center" is obsolete.[8] Quotes are optional if the value to the right of the equals sign doesn't contain spaces or special characters (class=wikitable would work as well). I personally prefer <br />, but both are equally correct. Rummskartoffel 14:58, 7 November 2021 (UTC)

Did something change recently with alternative text for images? Using Firefox on a PC, I could see the alternative text displayed when I hovered over an image. But now it's not displaying. What's up with that? — Mudwater ^(Talk) 02:31, 7 November 2021 (UTC)

Edited to add: Wait a minute. On the main page, I'm still seeing the alternative text. But I don't see it in album cover images in articles about albums. So, is something broken with the ((Infobox album)) template? — Mudwater ^(Talk) 02:34, 7 November 2021 (UTC)

Module:InfoboxImage was changed about 30 hours ago. – Jonesey95 (talk) 05:07, 7 November 2021 (UTC)

@Jonesey95: Yep, that was it. Thanks! Further reading: Wikipedia talk:WikiProject Albums#Alternative text for album cover in infobox — Mudwater ^(Talk) 15:59, 7 November 2021 (UTC)

I know there is template for automatic counting in table but I don't remember its name and maybe there is other way t achieve it? Eurohunter (talk) 15:03, 7 November 2021 (UTC)

Are you looking for ((row numbers)) or ((Static row numbers))? * Pppery * _{it has begun...} 15:36, 7 November 2021 (UTC)

@Pppery: What is the point of it if you have to count it manually? Eurohunter (talk) 15:55, 7 November 2021 (UTC)

Oh, sorry, I completely misunderstood what you were asking for. Ignore me. * Pppery * _{it has begun...} 15:56, 7 November 2021 (UTC)

@Pppery: Do you have idea how to make it to count automatically? Eurohunter (talk) 16:14, 7 November 2021 (UTC)

I remember there was probably two templates one for add all wanted numbers in the table into one template and second template with result. Eurohunter (talk) 16:59, 7 November 2021 (UTC)

Moved from Wikipedia:Help desk § How to subst #if:

 –  ― Qwerfjkltalk 17:47, 7 November 2021 (UTC)

I was trying to add an auto-categorising feature to a template, which works fine as

((#if:((#invoke:String|match|s=((subst::((subst:FULLPAGENAME))))|[[Category:Wikipedia scripts]]|plain=true|nomatch=))||The Category))

However when I try to subst into her a blank string. How do I fix this, and is there a better way to do this? ― Qwerfjkltalk 21:37, 6 November 2021 (UTC)

One of the regulars here might be able to help you, but I would suggest that WP:VPT is a better place to ask such a question. Beeblebrox (talk) 00:45, 7 November 2021 (UTC)

I can reproduce that behaviour. With subst:, it produces the text between the two pipes before "The Category", which happens to be blank. I don't understand the reason for that. (The other two subst: within s= don't seem to make any difference.) Certes (talk) 19:05, 7 November 2021 (UTC)

Are you forgetting to subst the #invoke? * Pppery * _{it has begun...} 19:09, 7 November 2021 (UTC)

That fixes it for me (and makes the other two subst: within s= necessary too). Certes (talk) 19:17, 7 November 2021 (UTC)

Thanks @Pppery, I was sure I'd already tried that ― Qwerfjkltalk 20:08, 7 November 2021 (UTC)

Hello! See User:Ʝ and User:DZoo — two users who seem to have disappeared during a rename from lowercase to capital letters. Their user pages' history show them being created by users with the lowercase name, but clicking their user link or contribs link brings you to the nonexistent username with the capital first character. I'm not sure what went wrong here. Tol (talk | contribs) @ 03:36, 8 November 2021 (UTC)

@Tol: This is being discussed at phab:T219279 - it isn't really about "lowercase" but a unicode problem that is being worked on, it may have some bugs that should be brought up at that phab task. — xaosflux ^Talk 14:34, 8 November 2021 (UTC)

Thanks, @Xaosflux. Tol (talk | contribs) @ 14:47, 8 November 2021 (UTC)

20:34, 8 November 2021 (UTC)

i want to merge two accounts but could i it's just mysql query bi (talk) 09:13, 9 November 2021 (UTC)

@Baratiiman: Short answer: No. We have never done this. Longer answer: we do not have the means to do this, and part of the reason that it was never provided is because of the requirements of CC BY-SA attribution - the same reason why we never delete accounts. As an example of a declined request to merge accounts, see phab:T154290. --Redrose64 🌹 (talk) 11:43, 9 November 2021 (UTC)

There doesn't seem to be a magic word or template that returns the name of the section in which it is placed (but maybe I haven't searched with the right query terms), and it would be useful in a number of situations. Is there some elegant or at least decent way to do this? If not, I'm planning a template which would include a unique token as a param (or maybe auto-generate it as a subst'ed hash of concat( ((Time)), ((SUBPAGENAME)) ), read the article with ((find page text)), and match it against a regex pattern matching the last section header name before the token. But that seems hacky and wasteful to me, and there ought to be a better way to do it. Is there? Somewhere I seem to remember reading about "section numbers", but I think that was just an addressability issue, and not a retrieval one.

My current use case is to provide decent query terms for the 'find' params in templates like ((Unreferenced)) and ((Expand section)) and others, where the first query term (|find= = "exact string" match) uses the article title, and the second query term (|find2= = unquoted search) would be the section name. This generally gives very good results when done manually, but optional params don't get used a lot, and the ability to automatically provide current section name as an unquoted query term in these templates would be a big improvement in the quality of search results provided by those templates. I suspect there would be a lot of applications for such a template, and it would be useful to have it be as efficient as possible. Thanks, Mathglot (talk) 22:13, 8 November 2021 (UTC)

Today this is not possible. There is a future where Parsoid is the one parser that might be able to do something like this keyword. Izno (talk) 22:15, 8 November 2021 (UTC)

Thanks, I thought not. In that case, as a fallback position of a template to replicate that functionality, can anyone find a better or more efficient solution than the one I have proposed? Mathglot (talk) 22:29, 8 November 2021 (UTC)

Section names are not fixed, they may be altered at any time (example). When editing, sections are referred to by number (for example, this section is no. 29 as I type this), but those may change at any time if, for example, old threads are archived or new sub-sections added to earlier sections. --Redrose64 🌹 (talk) 11:48, 9 November 2021 (UTC)

For some reason, the "User intent predictions" filters on Recent Changes will just randomly stop working when you have them applied, and when you reload the page, they are nowhere to be seen on the list of filters. Then, after a while, they reappear and magically start working again, and the cycle repeats itself. Why and how on earth is this happening?? GMX^(ping!) 01:42, 10 November 2021 (UTC)

Hi all

I'm working on a potential partnership with a large natural history organisation and I would like provide them with some metrics to give them an idea of the scale of readership of Wikipedia. If anyone is able to help me by giving me a metric of how many page views English Wikipedia articles on species receive per month I would really really appreciate it. I've tried using categories to get page views but I can't work out how to only get species articles, assume that there are a few infoboxes which could be used to identify species articles.

Many thanks

. John Cummings (talk) 21:23, 9 November 2021 (UTC)

All species pages should have a taxobox template. Searching for pages with template ((Speciesbox)) will pick up species pages using the automated taxobox system. If you also wanted subspecies and infraspecies you could also include template ((Subspeciesbox)) and template ((Infraspeciesbox)). And pages using the older manual taxobox system could be found by searching for pages with template (((Taxobox)) and parameter |species=. No idea about the page views side of things. —  Jts1882 | talk  09:24, 10 November 2021 (UTC)

Hi, if we follow this scenario

1. Go to the "Talk page" of an article, for example go to the talk page of Resolution (logic) i.e., the page Talk:Resolution (logic)
2. Press "New section" from top menu bar
3. Activate "Syntax highlighting" capability from the top toolbar, i.e., press the icon to activate it
4. Enter a short subject

Now in this place of scenario, if we try to sign our message via four tildes by pressing hyperlink existing on the bottom of that page, i.e., the hyperlink existing in "Sign your posts on talk pages: ~~~~" the resulting four tildes is always inserted in the "Subject textbox". Even if we put the cursor in the "Message textbox", and then put the that hyperlink again to sign the message, still these four tildes is always inserted in the "Subject textbox" and not on its correct position that is on the "Message textbox". Please correct this bug. Thanks, Hooman Mallahzadeh (talk) 17:28, 9 November 2021 (UTC)

Note: This bug is known and being tracked at phab:T252342. Rummskartoffel 18:03, 9 November 2021 (UTC)

I bet just adding

			} ).on( 'focus', '.CodeMirror', function () {
				$currentFocused = $( '#wpTextbox1' );

after MediaWiki:Gadget-charinsert-core.js#L-249 will do. Nardog (talk) 19:47, 9 November 2021 (UTC)

The CharInsert extension has code which seems to take care of CodeMirror compatibility, similar to what you suggest. We could copy that. Though I'm not sure what is the relationship between the charinsert gadget and charinsert extension. – SD0001 (talk) 04:49, 10 November 2021 (UTC)

I'm not sure what the relationship is either, but it's documented. It seems wrong to duplicate the code that should already be in the extension, but anyway I've copied over the extension's code per your suggestion and that seemed to fix it. Thanks for doing the research! — MusikAnimal ^talk 21:52, 10 November 2021 (UTC)

A long table in a Wikipedia article is causing a gray background to the right of the screen.

I have encountered this problem in several articles.
Examples:
Tesla_Model_S#Sales_by_country
RGB_color_space#RGB_color_space_specifications
Asteroid#Size_distribution
Motion_picture_content_rating_system#Comparison_table
List of AMD accelerated processing units#Features overview
Fiddler on the Roof#Casts
List of country calling codes#Tree list
Ranjit Singh#Biography#Early life
Sanjay Leela Bhansali#Filmography#Frequent Actor and Artist Collaborations as Director

And I came here after having discussions at Talk:Tesla_Model_S#Page_Display, Talk:RGB_color_space#Page_Display, and Talk:Asteroid#Page_Display.

I am using the iPad mobile website.

I am using Safari.

— Preceding unsigned comment added by Neel.arunabh (talk • contribs) 21:24, 4 November 2021 (UTC)

The grey background is the "natural" background colour for all Wikipedia pages. The white that you see in the main text area is specific to that area, it is superimposed on top of the grey and hides it. There's a trend at the moment to artificially constrain the width of displayed text, tables are not subject to that restriction so may protrude into the blank area on the right. Personally I would design web pages to use all of the available width, because if people really want the text to be narrower, they can resize the window by dragging the left or right edge. --Redrose64 🌹 (talk) 00:07, 5 November 2021 (UTC)

See Wbm1058's suggestion at Talk:Tesla Model S#Page Display, "The large number of footnotes included in some cells of the table is causing some columns of the table to be much wider than necessary. If all the citations were pulled from inside the individual cells and placed immediately below the table, the table would not require as much screen real estate.". We do not want last few columns of the table to cross the edge of the main text area. Neel.arunabh (talk) 01:14, 5 November 2021 (UTC)

What would you do instead? Cut it off level with the main text? No thanks. Space is there to be used, not set aside as fallow. --Redrose64 🌹 (talk) 09:46, 5 November 2021 (UTC)

I am really against the current structure of the tables. Imagine what it would be if the same thing happened in a Word document. Neel.arunabh (talk) 15:23, 5 November 2021 (UTC)

A skin level solution is basically required to fix this, as well as fixing our templates that use tables rather than e.g. divs (already on my long list of things to fix). For normal tables, only the first really fixes it; e.g. both Timeless and Minerva take care of the issue by overflow-x: scroll or some variant, while Vector probably does not have that code. phab:T131650 exists as one element of the issue, as does phab:T66577 (though the latter is written from the mobile perspective, the issue is relevant to New Vector's fixed content width). Maybe Jdlrobson knows the more recent task I'm pretty sure Alex was looking at a few months ago and which I can't find right now. Izno (talk) 15:33, 5 November 2021 (UTC)

Neel.arunabh, have you tried choosing "Use Legacy Vector" under Preferences → Appearance? It looks like your choice of skin (Vector 2.0, I'm guessing) means that you are depriving yourself of screen width for the text. Please try it; you might like it. – Jonesey95 (talk) 03:54, 11 November 2021 (UTC)

Jonesey95, "Use Legacy Vector" is already on in my preferences. Neel.arunabh (talk) 04:38, 11 November 2021 (UTC)

When I go to my watchlist there's a big ugly message about my interface language telling me nothing I haven't known for years, but with no apparent way to dismiss it. It appeared today. Is there some way of getting rid of this waste of screen? Thanks, DuncanHill (talk) 12:50, 5 November 2021 (UTC)

@DuncanHill: the best way to get rid of it would be to change your interface language to a supported language. In Wikipedia:Village_pump_(proposals)/Archive_184#Discourage_en-xx_UI_variants - there was widespread support to actively "discourage" editors from using patently broken interface languages. I just added an id to it, watchlist-summary-enxx-warning which you could hide in your common.css file. — xaosflux ^Talk 12:57, 5 November 2021 (UTC)

One of the most obnoxious features of the message is the claim "With this setting you will not be able to see many local messages, such as announcements made here" - if that were true I wouldn't be able to see it. Now it's one thing not to bother to make Wikipedia work properly for people with the en-gb setting, but to go out of your way to make things worse by putting big ugly notices in the way is quite another. I see the notice is also intruding on this page. I wouldn't go so far as to call it vandalism, I'm sure whoever thought this up had good intentions, but we all know whither that road leads. How do I hide it - on watchlist and wherever else it has been intruded? DuncanHill (talk) 13:00, 5 November 2021 (UTC)

You can hide this with:

#watchlist-summary-enxx-warning {display:none;}

In your Special:MyPage/common.css

— xaosflux ^Talk 13:06, 5 November 2021 (UTC)

Thanks, that seems to work. DuncanHill (talk) 13:11, 5 November 2021 (UTC)

• I'm the one who added it, based on the discussion I linked to above that I think supports that we actually "discourage" editors from using such settings. (I'm certainly involved there - and open to reversal by anyone else that want's to "close" that discussion with a different finding). — xaosflux ^Talk 13:10, 5 November 2021 (UTC)

  I wouldn't call that warning/notice an "announcement" really - and the message you are seeing there is not part of any workflow that will actually show what is more traditionally displayed as community "announcements". — xaosflux ^Talk 13:11, 5 November 2021 (UTC)

• I did pull it from the edit notice on VPT for now, that part may need some more work. — xaosflux ^Talk 13:12, 5 November 2021 (UTC)

There needs to be a button to dismiss it, at the very least. That wouldn't make me happy but it might make me less pissed off. You just can't go thrusting messages down people's throats all the time just because you don't approve of their use of the options you give them. DuncanHill (talk) 13:28, 5 November 2021 (UTC)

The one here on the VPT edit notice is gone, since it was messy anyway. As far as the watchlist header, the prior discussion appears to be quite supportive of actively discouraging people from picking that setting - we certainly disagree there but I'm open to more feedback from others below. — xaosflux ^Talk 13:52, 5 November 2021 (UTC)

@DuncanHill: You create problems for yourself by choosing en-gb. That's what happened at Wikipedia:Village pump (technical)/Archive 166#Unexpected behaviour of search/go where I asked you to please always mention it when you report issues with interface messages, and at Wikipedia:Village pump (miscellaneous)/Archive 67#Tags in Welsh where you didn't mention it. As one of the few users who both have en-gb and report interface issues, will you please either always mention it or change to en. At Wikipedia:Village pump (proposals)/Archive 184#Discourage en-xx UI variants I wrote:

"I once examined the full en-gb file and it only made around ten minor spelling and punctuation differences like color/colour, not different words like petrol/gasoline. For that you lose a lot of messages customized for the English Wikipedia, e.g. with links to our policies, processes and help pages. For example, compare the edit page for a fully protected page in en and en-gb (admins must log out to see it). en-gb users sometimes cause confusion when discussing the interface with others, and some help pages don't match what they see."

MediaWiki offers around 450 interface languages. All unregistered users and the large majority of registered users have en. We don't spend time customizing the interface for hundreds of languages here at the English Wikipedia. MediaWiki doesn't offer an option to automatically show a customized en message if there is no customized en-gb message. PrimeHunter (talk) 15:05, 5 November 2021 (UTC)

I finally specifically opened phab:T295164 about this problem - it could POSSIBLY be merged somewhere else - feel free to provide input there for now! — xaosflux ^Talk 15:21, 5 November 2021 (UTC)

@PrimeHunter: Starting off with "You create problems for yourself by choosing en-gb" really makes me not want to bother with you anymore. But I will say hundreds of languages which aren't English are pretty much irrelevant here, the problem is with a language which is. If I knew where to go and what to do to translate messages for en-gb I would lend a hand, but that does not seem to be wanted by anyone. DuncanHill (talk) 15:47, 5 November 2021 (UTC)

@DuncanHill: en-gb translations are done at translatewiki.net, you can help out there. Portal:En shows there was only 58 en-gb translations in the last 30 days, which is less than is necessary for a good user experience. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:21, 5 November 2021 (UTC)

ME TOO -Roxy the sceptical dog. wooF 16:43, 5 November 2021 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: Thanks for the link. I think I've found the right place there - it's not entirely clear where things for en-wiki are. DuncanHill (talk) 17:40, 5 November 2021 (UTC)

From a technical note, I don't think that translatewiki is a solution to the problem: it is great for ensuring that default messages are accessible in all languages - it is not good for translating a single project's localized messages. — xaosflux ^Talk 17:55, 5 November 2021 (UTC)

@DuncanHill: you may find this useful for starting out in translatewiki. As Xaosflux said above, translatewiki is good for translating global default messages. Enwiki is unique in that we have a larger number of localised messages compared to other language projects. Translating them to en-gb is up to one of the admins of enwiki. For example MediaWiki:Gadget-HotCat/de is the German translation of enwiki's localised MediaWiki:Gadget-HotCat, which overrides the global MediaWiki:Gadget-HotCat. Like this a separate interface message can be locally set up at MediaWiki:Gadget-HotCat/en-gb and so on for other messages. Nobody seems to be interested in doing this, so you will have to depend on translatewiki. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 19:11, 5 November 2021 (UTC)

Why don't we just run a bit to create /en-gb and /en-ca customizations identical to the English defaults for all of the currently-customzied MediaWiki messages? That would be easier than all of this arguing. * Pppery * _{it has begun...} 16:47, 5 November 2021 (UTC)

@Pppery: well we did just discuss this at VPR (see link above) and the overwhelming feedback was to discourage these - not try to keep them going. — xaosflux ^Talk 16:50, 5 November 2021 (UTC)

Why is this issue being re-litigated here? This is a perennial Village Pump issue (link to dozens of threads where en-gb is mentioned as an issue). The VPP thread was pretty much unanimous for discouraging the choice of en-gb in this context. It is now being discouraged. A CSS workaround has been provided for people who resist the discouragement. Any time this comes up again, we can respond with a boilerplate message explaining that the use of that preference is discouraged because en-gb interface messages are not maintained, instructions for setting it to a user-friendly option, a link to a relevant phab task that would make the whole thing moot if fixed, and CSS instructions for making the discouraging message go away (caveat customizer, of course). – Jonesey95 (talk) 18:09, 5 November 2021 (UTC)

Why on Earth are we telling users to stop using the setting for their own language? If en-gb is provided as an option, it should be properly supported. If it is not supported, remove it from the list of options. If it is supported, stop discouraging people from using it. The watchlist notice is inappropriate. Did you actually speak to any en-gb users before slapping them with a warning message that makes no sense to them? A custom CSS workaround is not suitable because a) it's an obscure kludge and b) the vast majority of users won't known to use it. Modest Genius ^talk 13:12, 9 November 2021 (UTC)

@Modest Genius: There's a difference between saying that some feature should be "properly supported" and actually persuading people to perform that support. The people who maintain the various interface languages are volunteers, just like we editors are volunteers. If nobody is interested, it will at best stagnate, at worst deteriorate - as has been shown. As noted above, there was an RfC earlier this year. --Redrose64 🌹 (talk) 14:45, 9 November 2021 (UTC)

@Redrose64: I'm not asking you to support it. I'm saying there's no point in giving users the option if it just triggers an error message saying it isn't supported, particularly one that is confusing, self-contradictory, and cannot be dismissed. Either allow users to select en-gb without hassling them about it, or remove the option entirely. Telling them off for doing something we presented as a valid option is nonsensical. Modest Genius ^talk 19:38, 11 November 2021 (UTC)

So, when is the big ugly message going to vanish? -Roxy the dog. wooF 14:48, 9 November 2021 (UTC)

Might I ask why you are against selecting "en - English" as your language? --Redrose64 🌹 (talk) 15:03, 9 November 2021 (UTC)

Sure, and this for me is obviously the important point. It isn't clear which variety of english "en - English" is. I suspect it is probably american, in which case I want no truck with it as it is spelled rong. I hope that makes sense. -Roxy the dog. wooF 15:14, 9 November 2021 (UTC)

It's not American (if it were, it would be described as "American English" in the selection list), nor is it Australian, Indian or South African. It's an internationalised form that should be understandable to anybody for whom some variety of English is used in day to day communication.

Of greater problem to me as an editor is in talk page discussions where somebody describes a matter as "moot", the meaning of which in American is directly opposite to its meaning in British. It's the same problem when a motion is "tabled". Neither of those conflicts can be resoved by an interface language setting. --Redrose64 🌹 (talk) 15:31, 9 November 2021 (UTC)

User:Redrose64 thanks for responding, fyi I have changed from GB to En. If you want to stop the old farts like me from complaining, the best option is to remove GB altogether. Thanks again. -Roxy the dog. wooF 14:19, 11 November 2021 (UTC)

Graham Beards and I have observed that issues result when a single article uses both the score extensions with sound and the ((Listen)) template (e.g. FAC Symphony No. 4 (Mahler) and FA Piano Concerto No. 24 (Mozart), as well as articles with more traffic like Symphony No. 9 (Beethoven)). On my end, the presence of the two causes the score's sound files to "reload" annoyingly before being formatted in a similar style to the sound file in the Listen template. On Graham Beards' end (using the latest version of Chrome browser), the presence of the two causes the scores' sound files to be unplayable. Furthermore, we both found that this problem disappears when the Listen template is removed from the articles. Any help with fixing this problem would be greatly appreciated, and would undoubtedly improve the reader experience on many music articles. GeneralPoxter (talk • contribs) 23:17, 9 November 2021 (UTC)

This seems to stem not from anything specific about ((Listen)) but from how Score and AV media embedded using [[File:... interact in general. If the page only has scores, the browser's native HTML5 player is used, but any media embedded via [[File:... triggers the loading of MediaWiki's own player, which replaces the HTML5 player, hence the delay.

I assume Graham Beards has turned "New video player" on in Preferences. The new player apparently doesn't work with Score at all (phab:T245377). Nardog (talk) 03:04, 10 November 2021 (UTC)

I've filed a task: phab:T295514. Nardog (talk) 23:40, 10 November 2021 (UTC)

Thanks, good to hear. GeneralPoxter (talk • contribs) 00:23, 12 November 2021 (UTC)

In the text below, how can I display a list of the contents of the category as text, rather than just linking to the category ? If I remove the first colon, it just adds the page to the category; what I want is to produce a list of the articles at FAR. Thanks in advance, dumber than I look.

• Articles listed at FAR are:

Category:Wikipedia featured article review candidates

SandyGeorgia (Talk) 22:44, 11 November 2021 (UTC)

@SandyGeorgia: Does the categorytree extension do what you want? try ((#categorytree:Wikipedia featured article review candidates|mode=pages)) 192.76.8.91 (talk) 00:16, 12 November 2021 (UTC)

Bingo ! Thank you so much, 192! Best regards, SandyGeorgia (Talk) 00:22, 12 November 2021 (UTC)

@SandyGeorgia: Minor point, but if you want you can add "hideprefix" onto the magic word to get rid of all the "talk:", like so: ((#categorytree:Wikipedia featured article review candidates|mode=pages|hideprefix)). Doesn't really make any difference to the functionality, but it would look a bit better where you're using it. 192.76.8.91 (talk) 00:43, 12 November 2021 (UTC)

And to get it to just print out a list of titles use ((#categorytree:Wikipedia featured article review candidates|mode=pages|hideprefix|namespaces="1"|hideroot=on)) 192.76.8.91 (talk) 00:54, 12 November 2021 (UTC)

Amazing! Now how do I barnstar the heck out of an IP ?? See the last green box in this mockup in my sandbox, where you can see I now have exactly what I want. Thank you! SandyGeorgia (Talk) 01:33, 12 November 2021 (UTC)

Is there a straightforward way of getting the page creator of a page via the MW API? It's listed if I go to, for example, https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=info, but doesn't appear to be listed when doing &prop=info in the API. I could ask for the user that made the oldest revision via &prop=revisions&rvprop=user&rvlimit=1&rvdir=newer, but that would mean doing a second API call since I'm already asking for info on the most recent revision (and it comes with the other limitations of prop=revisions, such as only being able to query one page at a time). --Ahecht (TALK
PAGE) 23:12, 10 November 2021 (UTC)

The XTools gadget listed in Preferences can do it. I think its source code is at mw:XTools/ArticleInfo.js. – Jonesey95 (talk) 00:04, 11 November 2021 (UTC)

Interesting, although it looks like it's still going to have to be a separate API call, and a separate call for each page. --Ahecht (TALK
PAGE) 00:59, 11 November 2021 (UTC)

Using the MW API, I believe querying the user of the first edit is the only way. – SD0001 (talk) 11:21, 11 November 2021 (UTC)

@Ahecht: Are you checking all 6.5m and need to get through it quickly; or more interactive application of small numbers with high response speed? I can possibly help with the former, a regularly updated data dump. -- GreenC 22:58, 11 November 2021 (UTC)

@GreenC It's more the later. It's a userscript for for cleaning pages from your watchlist you haven't touched recently. Fetching revision info on a few thousand pages is quite slow via the API, I was trying to avoid having to do it twice to filter out pages that you created. --Ahecht (TALK
PAGE) 02:48, 12 November 2021 (UTC)

If you're only looking for whether the pages were created by the current user, list=usercontribs&ucshow=new may be faster, though it obviously depends on the ratio between watchlist items and creations. I just tried mine and got lots of user talks, so you may want to specify ucnamespace. Nardog (talk) 02:58, 12 November 2021 (UTC)

Why are there Special:RevisionDelete and Special:Undelete, but no Special:Delete nor Special:Protect? NguoiDungKhongDinhDanh 12:07, 12 November 2021 (UTC)

They just aren't built upstream. See phab:T233987 for Special:Delete work; if you want a similar request for Special:Protect you can file a feature request. In general, the workflow for using these functions normally stems from already being on a page and using an ?action value, or using the API. Don't think these would really get used much. — xaosflux ^Talk 12:40, 12 November 2021 (UTC)

Starting within the past couple of days, whenever I paste something into the edit window, my cursor immediately jumps to the top of the window. How can I prevent this? Using Modern skin in Firefox. Nikkimaria (talk) 03:03, 12 November 2021 (UTC)

@Nikkimaria are you using WikEd? If so, I think this is an incompatibility issue between FF & WikiEd as I'm having the same issue; but only in FF, swap to Chrome or Opera and there is no problem. Nthep (talk) 12:15, 12 November 2021 (UTC)

Hm. Yes, but I've been using it for quite a while and this is a new issue. Nikkimaria (talk) 14:28, 12 November 2021 (UTC)

@Nikkimaria I think it's something to do with FF 79. Like you I had no problem with previous versions of FF. I'm just having to remember to switch WikiEd off when I want to paste something. Nthep (talk) 15:04, 12 November 2021 (UTC)

I am not using WikiEd, and am having similar problems. SandyGeorgia (Talk) 17:22, 12 November 2021 (UTC)

Hi -- not sure if this problem is me or the Insert Link feature. When editing, if I paste a complete URL into the Target Page/URL box of the Insert Link tool in the edit window, I get the usual "The URL you specified looks like it was intended as a link to another wiki page. Do you want to make it an internal link?" message. However, when I click Internal Link, nothing happens. In the past, it would reformat a full URL to be a proper internal link and change the radio button. I used it constantly. Now it does nothing.

This change came as the same time as some other look-and-feel changes to this tool (I now see preview images, tool has a more DHTML feel to it) so I am wondering if it got updated and this is a bug, or there is something about my configuration that has maybe changed. I haven't knowingly changed anything in my configuration. I am using a Mac (Big Sur) and it happens across all three browsers (Chrome, Safari, Firefox, latest non-beta versions of each). Vector skin. Here's two screenshots with examples. If I paste in a complete URL, when I click "internal link" in the second screenshot, nothing happens, it just returns me to the same window. Thanks for any help/advice.

Jessamyn (talk) 00:15, 11 November 2021 (UTC)

Yep, can reproduce, I bet this is the relevant line. Pinging Samwilson. Nardog (talk) 00:44, 11 November 2021 (UTC)

@Jessamyn and Nardog: Thanks for finding this bug and letting me know! Sorry about this. I've created T295517 and will try to get it fixed soon. —Sam Wilson 00:53, 11 November 2021 (UTC)

As I suspected, replacing the line with insertLinkTitleInputField.getField().setValue( match[ 1 ] ); seems to do the job. But I'm surprised the function 1) keeps underscores instead of turning them into spaces and 2) doesn't decode percent encodings. I bet users of wikis in other languages have found it useless. Nardog (talk) 05:14, 11 November 2021 (UTC)

@Jessamyn I just wanted to acknowledge and thank you for this exceptionally well-written and detailed bug report :) — MusikAnimal ^talk 02:52, 11 November 2021 (UTC)

Awww thank you! I've worked in tech support before, so I like to think I can make a decent report. The little info box above the posting box really helps a lot. Jessamyn (talk) 04:13, 11 November 2021 (UTC)

Random aside — This change came as the same time as some other look-and-feel changes Does anybody have a link for that change? Ta — GhostInTheMachine ^{talk to me} 12:44, 11 November 2021 (UTC)

@GhostInTheMachine This is part of the Warn when linking to disambiguation pages project from Community Tech, based on the #2 wish in the 2021 survey. The visual changes you speak of specifically were a result of phab:T289214. — MusikAnimal ^talk 15:26, 11 November 2021 (UTC)

Thanks. So the change to the editor linky thing would have gone live in 1.38.0-wmf.5 on 21 October 2021? — GhostInTheMachine ^{talk to me} 19:20, 11 November 2021 (UTC)

@GhostInTheMachine It looks like the first big change was deployed with wmf.4 which went live on October 14. There were subsequent patches that went out with wmf.5 which I think is why the Phabricator bot confusingly changed the tag to wmf.5. — MusikAnimal ^talk 16:49, 12 November 2021 (UTC)

Thanks — GhostInTheMachine ^{talk to me} 17:49, 12 November 2021 (UTC)

NOTE: this is a technical issue that should be evaluated by software engineers and webmasters of wikipedia website(s).

First of all, I do not want to be disrespectful to anyone so, please, take these user observations for what they are (maybe all of them are already well known): simple thoughts of an occasional user.

Introduction
In Wikipedia:Village pump (miscellaneous)/Archive 68#Very_big_pages someone has arisen the problem of long delays (i.e. till 5..7 seconds) when visiting big wiki pages, specially the first time someone retrieves one of them after sometime (days or weeks?) nobody has visited it.

In practice the topic being discussed was about how to lower the size of big / long wiki pages because someone thought that most of the wait time was due to client browser struggling to retrieve and visually render such big pages (HTML code between 1MB and 1.6MB) and having a PC with CPUs not slow and enough RAM, he was worried about what could happen to smartphones and other mobile devices with much less HW resources.

Someone else replied that he did not notice such a long delays, at most 1..2 seconds, so I contributed to the discussion with my thoughts too and I found out that maybe something in wiki pages retrieval mechanism between web servers and browsers could be improved.

Here I do not want to discuss about the problem of long delays for the first time retrieval of big pages because it's a too technical thing that regards only wikipedia internal technical stuff; I have already written something about it in the above mentioned wiki section page.

Talking about the impact of slow response in user (web) interfaces, see also wiki article about responsiveness, I have noticed that web caching of wiki pages might be improved noticeably in order to decrease a lot of unnecessary web traffic load that probably burdens web applications and DB (database) too.

Caching assumptions
If a user is logged in, it looks like that wiki pages are never cached by browser (this is right, at least when editing a page), instead if user is logged out (not logged) pages are temporarily cached (this makes a noticeable difference) and so if they have already been retrieved (recently, within 1 minute) and they have not been modified then they are rendered in less than 0.2..0.3 seconds on a medium speed (high speed, single CPU) PC.

Right know cacheability of a wiki page depends also on:

• type of content encoding format (compressed or not);
• value of cookies;
• authorization;

because of "Vary" header, which is right.

Cookies contain also a session identifier that usually is dismissed when client browser is closed, in any case caching of wiki pages will always be session bound (it will last only till browser is kept open and only for users not logged in).

Current behavior / problems detected
Current caching of wiki pages by browsers is far from being perfect because of the following technical issues:

• wikipedia web servers look like to use a last modification date-time for wiki pages, maybe this is always sufficient to detect their changes but it requires absolute integrity of server(s) clock time;
• at least one wikipedia web server used for static images (i.e. upload.wikimedia.org /common/thumb/*) sends neither "Last-Modified" nor "ETag" headers and so static images served by that web server are always fully reloaded when a page using them is displayed (as those images are rarely used in wiki pages this is not a big deal but anyway it is very odd and I guess really not necessary);
• in some cases header "Date" is not updated in server responses, but I am not sure about this case, maybe it depends on behavior of some web cache;
• caching of wiki pages depends also on cookies and cookies sent by browser change around once a minute, so when they change then browser has to invalidate all its cached copies of wiki pages, even those read just a few seconds before that event; this means that if the same wiki page is requested again by browser after its cookie has changed then the entire wiki page has to be retrieved, instead of just asking the web server if it has changed or not; this may be an issue that increases a lot web traffic and load of web servers, web applications, DB, etc. behind them.

In web server responses, it looks like that "Cache-control" and "Expires" headers already have proper settings.

Goal to improve website response times of wiki pages
The aim should be to always force browsers to ask web servers if a wiki page has been changed or not every time it is going to be displayed by browser (so statistics about number of pages showed by users should not be affected by this improvement) by avoiding the premature invalidation of cached wiki pages; of course just asking that is much faster than retrieving the whole page every time it is visited by a user, specially if wiki page is big (there are wiki pages that do not change for hours, days or even months).

Proposals to reach goal of good cacheability of wiki pages
These are a few proposals in order to improve cacheability of wiki pages.

Web / application server(s) side
1. Wiki pages accessed by logged out users are already cacheable (even if only for very short period of times right now);

2. Wiki pages accessed by logged in users might be cached (in a far future) and only when not in editing mode, by using a unique identifier for each version/presentation type of a certain page to be used in "ETag" header, i.e. it might be composed by wiki page revision number (or date-time of its modification) + user-id + user settings/customization revision used for the pages;

Client browser side
3. Value of Cookies should not change every minute (at least for users not logged in). The problem is to find out a solution to avoid this periodic change without loosing their information data (details on request).

Something about improving HTTP caching could be done also for scripts and stylesheets; they are not always cached by browsers as they should be and besides this fact, sometimes their retrieval is a bit slow; specially when you are logged in and wiki servers are under load, you can see that wiki page is first visually rendered with standard browser fonts and then, after 0.3 .. 0.6 seconds, with proper text fonts because download of some style sheet is completed after wiki page has started to be shown in browser.

Conclusions
Doing above 3 suggested modifications, could allow caching of wiki pages feasable for an entire user session (until browser is closed), thus decreasing a lot the size of HTTP responses for wiki pages and the load server side.

Thank you for your attention and I'm sorry if I bothered you with already known issues. Ade56facc 13:05, 11 November 2021 (UTC)

Ade56facc I took the liberty of creating a Phab ticket T295556 which is better suited for discussions of this nature. ~ 🦝 Shushugah (he/him • talk) 14:23, 11 November 2021 (UTC)

Thanks for the ticket (I did not know about that reporting system). Ade56facc 14:40, 11 November 2021 (UTC)

I'm pretty sure these are all known and all have various reasons for being the way they are. For instance you make an assumption that a revision renders the same, but they do not for logged in users (for various historic reasons which are hard to undo (a 10 year project now)). But you are right that the biggest reason a page takes VERY long to load indeed is the complexity of turning wikitext into HTML when there is no cached copy of that available. —TheDJ (talk • contribs) 15:25, 11 November 2021 (UTC)

@TheDJ thank you for your comment, anyway I did not make that kind of assumption because I already wrote that for users logged in wiki pages are never cached; I was referring to an identifier usable in "ETag" HTTP header (that can be unique only for its associated page name, i.e. it could also be a revision number of the wiki page); anyway I have found out that maybe it is really not possible that two users can update the same page in the same second (even if they edit different sections) so maybe also a "Last-Modified" page date-time would suffice for caching purposes; the important thing would be to have the same behavior for all web servers serving wiki pages. Ade56facc 21:30, 11 November 2021 (UTC)

Ade56facc Did you only see the "Not-Modified" tag wrong when logged in, or also when logged out? It matters because there is more caching server side when logged out. Even an simple addition of an link to the sidebar changes the html of an page, making it hard to cache pages. IP users can't do customizations, so they can be cached server side more than logged in users. Just in case you are unaware, there are 3 cache servers, one in Europe, one in Asia and one in West USA, while the two main servers are in East USA (and one more planned in Europe). Also, please simplify the phabricator task by changing the description, it is not going to gain any traction like this.--Snævar (talk) 15:35, 12 November 2021 (UTC)

@Snævar Thank you for the info, as stated above I investigated things mainly for the "logged out" (IP users) case. Answering to your question, right now I am almost sure to have seen an "ETag" header instead of a "Last-Modified" header for a wiki page while not logged in, anyway as I had just logged out I cannot 100% bet that everything were OK on "Cookie" side. I'll verify in next future if it happens again. Talking about caching wiki pages for logged in users I'm almost sure that this could be done without too many complications; it's just a matter to use a unique cache identifier for each combination of wiki page revision number (or date-time of last modification) + user ID + customization level / revision made to the page by user, taking in account that skins / stylesheets, etc. are separate objects from page content. After all customized pages of logged in users should be cached only by their browsers (private caches), not by shared caches, and also this can be done easily.

I did not create the above mentioned ticket (see above, user Shushugah) and I do not know how to change its title or its description (because I am not allowed to), anyway I have added more details to that ticket, in a couple of comments, as requested. --Ade56facc 17:59, 12 November 2021 (UTC)

I used to use this skin, yet later I found out that it no longer exists, thus I had to use Timeless instead, making WikiEd unusable. Later I used the new Vector instead, making WikiEd usable again, which delights me. But I still wonder why Modern, a very elegant skin, is not longer existent and why WikiEd can not be used while using Timeless. May fellow Wikipedians tell me?--RekishiEJ (talk) 12:45, 8 November 2021 (UTC) added "use" 05:39, 9 November 2021 (UTC)

@RekishiEJ: It does still exist, but only for people who already have it selected - it's not available to those already using another skin (but see below). More info at Wikipedia:Village pump (technical)/Archive 191#modern skin on Commons and WT:Skin#'Modern' not selectable any longer. In short: the more skins that we have, the greater the maintenance burden - every new feature and bugfix needs to be tested against all existing skins to ensure compatibility. So when new skins get introduced - such as Timeless and Minerva - the older ones with the least use get retired.

But for the time being, there is an unofficial workaround:

1. Go to https://en.wikipedia.org/wiki/Special:Preferences?useskin=modern#mw-prefsection-rendering
2. Select "Modern"
3. Click Save

This won't work forever, at some point you'll be forcibly switched to Vector and there will be no way back. --Redrose64 🌹 (talk) 14:31, 8 November 2021 (UTC)

And as far as "WikiEd" goes, that is a personal user script - you can follow up at User talk:Cacycle/wikEd. — xaosflux ^Talk 14:35, 8 November 2021 (UTC)

Well, Wikipedia and other Wikimedia projects should no longer consider compatibility for older browsers (i.e. only the newest stable version of any non-discontinued browser should be considered), since doing so greatly reduced burden, some websites stop Internet Explorer support (some only support IE later than 8), and Modern can be revived.--RekishiEJ (talk) 15:16, 8 November 2021 (UTC)

And in fact, Wikipedia supports only IE9 and above presently (soon to change probably since little-to-no traffic is generated from either IE9 or 10). But that's still many, many versions of Internet browsers that need to have minimal support, because a world-top-15 website dedicated to the mission of knowledge does not have the luxury of eliminating support for arbitrary old browsers. --Izno (talk) 16:58, 8 November 2021 (UTC)

But this is irrelevant to whether Modern is directly support of course. Modern was not dropped because it did(n't) work in certain browsers but because it was totally unmaintained, little-used, and an ancient skin to boot. Izno (talk) 16:59, 8 November 2021 (UTC)

@Izno:I mean if Wikipedia drops support for all older browsers maintenance will become much simpler, thus keeping Modern does not make maintenance more burdensome than now.--RekishiEJ (talk) 05:39, 9 November 2021 (UTC)

The impending retirement of Cologne Blue and Modern is is nothing to do with browser support but the lack of willing maintainers - they're volunteers just like editors, under no compulsion. Skins are retired when few people are using them and nobody wants to maintain them, and their continued presence is a bigger burden than the disappointment of a few niche users. Having a choice of four or so skins is a luxury that other popular websites do not offer - Facebook, for example, periodically introduce a new skin (or "theme", I think they call it) and although they run two in parallel for a few weeks, they then drop the older one like a stone. --Redrose64 🌹 (talk) 15:21, 9 November 2021 (UTC)

And the Chinese edition still retains Modern, despite having Monobook, Vector, Timeless and Minerva.--RekishiEJ (talk) 15:26, 8 November 2021 (UTC)

@RekishiEJ: zhwiki no longer offers Modern to switch to (c.f. w:zh:Special:参数设置#mw-prefsection-rendering) - however just like here there is still a hack to put it in (for now) and if you already have it set it is still available (for now). — xaosflux ^Talk 15:37, 8 November 2021 (UTC)

Xaosflux WikEd is offered as a gadget. --Izno (talk) 16:58, 8 November 2021 (UTC)

Indeed, if WikEd does not work with Timeless, that means WikEd should be fixed/corrected. --Izno (talk) 16:58, 8 November 2021 (UTC)

@Izno: as WikEd is labeled as a gadget that is maintained by a single user - going to that user is still the primary place to ask for work to be done. I suppose if this is confirmed, we certainly can flag the skin dependencies in MediaWiki:Gadgets-definition in the meantime. — xaosflux ^Talk 17:26, 8 November 2021 (UTC)

While the modern skin is no longer maintained for wikipedia, it is open source and still available at [12]. Most UI elements of modern could be recreated as a modification to the current default vector skin with user css and javascript, if someone with css knowledge wanted to take the time.Dialectric (talk) 10:02, 12 November 2021 (UTC)

The technique can also be used for Cologne Blue:

1. Go to https://en.wikipedia.org/wiki/Special:Preferences?useskin=cologneblue#mw-prefsection-rendering
2. Select "Cologne Blue"
3. Click Save

The same caveats apply as for Modern. --Redrose64 🌹 (talk) 00:05, 13 November 2021 (UTC)

This just started happening. I don't think it's a software update on my end (Microsoft Edge, Windows 10). But certain words get underlined in blue when I edit.

Actually, it just happened with "edit" and I saw a message saying there should be a space after punctuation. Then I saw the word "ignore". I c;icked on that and it went away. Maybe it's not Wikipedia.

No, there it is again. It wants me to click again to ignore.— Vchimpanzee • talk • contributions • 23:53, 10 November 2021 (UTC)

@Vchimpanzee: that sounds like a spelling and grammar tool in your browser, likely Microsoft Editor. — xaosflux ^Talk 00:12, 11 November 2021 (UTC)

It doesn't say how to get rid of it.— Vchimpanzee • talk • contributions • 00:26, 11 November 2021 (UTC)

Most likely the fix is something like this: Go to your web browser's Add-Ons or Extensions menu, and click to disable the add-on that is causing this message to appear. – Jonesey95 (talk) 00:30, 11 November 2021 (UTC)

It doesn't seem to be listed, but Wikipedia is the only place where I'm seeing this.— Vchimpanzee • talk • contributions • 00:42, 11 November 2021 (UTC)

Try using another browser to verify? — xaosflux ^Talk 01:19, 11 November 2021 (UTC)

It doesn't happen if I'm not signed in. I'm reluctant to sign in on two different browsers at the same time.— Vchimpanzee • talk • contributions • 23:21, 11 November 2021 (UTC)

You can have more than one browser open and be logged in on all of them simultaneously - each browser will require a separate login action. They won't conflict with one another, until you log out using the log out link at top right - which will log you out of all, because you can't log out selectively other than by going to the cookie management feature of one of the browsers, and deleting the login cookies. --Redrose64 🌹 (talk) 23:32, 11 November 2021 (UTC)

Everything looks very different here but I'm not getting the blue line.— Vchimpanzee • talk • contributions • 00:16, 12 November 2021 (UTC)

Bottom line is, mediawiki doesn't include a spelling or grammar checker. So either you loaded some script from here, or it is your browser. — xaosflux ^Talk 00:28, 13 November 2021 (UTC)

The data-sort-value parameter for sortable wikitables does not work with negative numbers. It will sort lower negative numbers after higher negative numbers, while doing the reverse for positive numbers. For example, the parameter will sort 2 after 1, and at the same time -2 after -1. This results in a sequence similar to -1, -2, -3, 0, 1, 2, 3. What I want is -3, -2, -1, 0, 1, 2, 3. Is this intended behaviour? How do I fix it? 122.61.79.96 (talk) 04:27, 13 November 2021 (UTC)

It should sort numerically if your code is correct:

Value
Q 1
Q 2
Q -1
Q -2
Q -3
Q 0
Q 3

Please post your real example as a table or link to it. Maybe you used another character for minus or had something in the column which made it choose alphabetical sorting instead of numerical sorting. See Help:Sorting#Configuring the sorting. PrimeHunter (talk) 06:25, 13 November 2021 (UTC)

How to link (592044) 2014 MB70 to wikidata (as a redirection) ?

Look at (364171) 2006 JZ81 for instance.

--Io Herodotus (talk) 06:59, 13 November 2021 (UTC)

wikidata:Help:Sitelinks#Linking to Wikimedia site pages says: "If you really want to connect a redirect page to an item, you may first temporary deactivate the redirect page (e.g. blanking it), and connect it to the item, then restore the redirect." I don't know whether there are guidelines on when to do this. (592044) 2014 MB70 redirects to a single table row. The only sitelink in 592044 (2014 MB70) (Q30748802) is fr:(592044) 2014 MB70. Even if you know no French, you can get more information from the French article. PrimeHunter (talk) 08:02, 13 November 2021 (UTC)

Thank you, it works (I'm the one who wrote the French article). --Io Herodotus (talk) 08:31, 13 November 2021 (UTC)

Wikidata reached a consensus to allow redirects in 2018. Wikidata:Sitelinks to redirects suggests that links to redirects are prevented only by a Wikidata software deficiency which may be fixed later. We raised phab:T54564 in 2013, which has attracted useful comments but no action. (See also phab:T120778.) Certes (talk) 15:33, 13 November 2021 (UTC)

I forgot where I can request it but I received entry on my talk page which I think should be removed for few reasons. Eurohunter (talk) 08:42, 14 November 2021 (UTC)

@Eurohunter: First, don't draw attention to it by posting on a public noticeboard (like this one). Second, undo the offending edit. Third, see CAT:REVDEL or if it's really sensitive, WP:OVERSIGHT. But I don't see anything in the recent history of your talk page that warrants anything stronger than a normal WP:UNDO. --Redrose64 🌹 (talk) 10:52, 14 November 2021 (UTC)

@Redrose64: True I had similar entry few years ago but I didn't remember where to go so I will save CAT:REVDEL this time. Eurohunter (talk) 20:31, 14 November 2021 (UTC)

When I point my mouse at Kópavogur I see "Kópavogur ⋅ actions ⋅ popups Stub, 6.7kB, 45 wikiLinks, 6 images, 4 categories, 5 days 9 hours old {" but none of the article text. I can't see what is causing this in the article. Can anyone fix it? Thanks, DuncanHill (talk) 23:24, 13 November 2021 (UTC)

@DuncanHill: it is mad about the <mapframe> section - haven't found out why yet though. — xaosflux ^Talk 00:02, 14 November 2021 (UTC)

Converting that to ((Maplink)) may fix it, I'm not very familiar with that template though. — xaosflux ^Talk 00:07, 14 November 2021 (UTC)

@Xaosflux:, Jonesey95 has moved the mapframe and it is now behaving properly. DuncanHill (talk) 17:48, 14 November 2021 (UTC)

What I did was a hacky workaround, but it mostly gets the job done. It seems like the Navigation pop-ups should be able to work around this apparently simple use of mapframes. Also, where does the strange capitalization of "wikiLinks" come from? I don't use nav pop-ups, but it smells a little beta to me. I don't see either of these bugs listed in the phab bug list, but I didn't look too extensively. – Jonesey95 (talk) 20:53, 14 November 2021 (UTC)

Hello friends!

We have new information on IP Masking for you. Thank you for being patient as the project unfolds.

IP masking hides the IP addresses of unregistered editors on Wikimedia projects, fully or partially, from everyone except those who need access to fight spam, vandalism, harassment and disinformation.

So far, we have had conversations on why we are masking IPs and the tools you will need to continue fighting abuse. What is up next is, we want to share with you details about the implementation itself.

This update answers some likely questions you may have about who gets to view IP addresses and the various IP Masking implementation approaches and how each of them will impact the communities.

Please see this section for the latest information.

If you need a background on IP Masking, there’s a summary here for you.

–––

Best regards,

STei (WMF) (talk) 15:07, 15 November 2021 (UTC), on behalf of the Anti-Harassment Tools team.

Is it possible to watch a page for the addition of a particular word or phrase? Thank you, DuncanHill (talk) 16:39, 15 November 2021 (UTC)

@DuncanHill: natively no; locally - in a round about way using the abusefilter; client-side: I suppose you could write a userscript tha fetches the diffs on your watchlist, and hides lines if conditions are met (e.g. page=X and diff !=(array of phrases)). I don't see any listed at Wikipedia:User_scripts/List#Watchlist - and this would likely be quite slow. — xaosflux ^Talk 17:01, 15 November 2021 (UTC)

@Xaosflux: OK thanks, I thought it was a bit of a long-shot! What I was hoping to do was find some way of alerting me if anyone asked at WP:RX about David Lloyd George, as I have a fairly decent library of works by or about him, and would be happy to help anyone looking for references within it. I do have the page watchlisted, and check it regularly, but some sort of specific notification would ensure I didn't miss anything. Mind you, I think it's usually me asking about him there, but you never know! DuncanHill (talk) 17:11, 15 November 2021 (UTC)

I have for quite a long time been frustrated by the behavior of autocomplete in search boxes, where I type my search string, type enter, and before my search is entered I get a different autocomplete string replacing it. This evening I saw the same misbehavior in an edit summary box, where I typed the edit summary I wanted, was about to type enter, and it was already replaced by something different that I didn't want. This is very dangerous behavior, endangering my browser privacy and making accidental incivility likely, not to mention a lot of confusion. Is there some way of disabling it? I didn't see anything in edit preferences. Is it something specific to my browser (OS X Firefox, or sometimes Chrome)? Is it something that affects other people and if so can it be disabled more generally? —David Eppstein (talk) 07:51, 15 November 2021 (UTC)

After posting this I found the search preference pane which at least controls the search box. I hope the edit summary replacement was just a glitch and not a harbinger of prolonged misbehavior. While I'm here: I've also starting today been unable to disable syntax highlighting in wikitext editing windows, no matter what I do to the "syntax highlighting" checkbox in the gadget preference pane. I don't want syntax highlighting at all. How do I make it stop? —David Eppstein (talk) 07:51, 15 November 2021 (UTC)

Autocomplete in the edit summary is a browser feature. --Redrose64 🌹 (talk) 08:38, 15 November 2021 (UTC)

For syntax highlighting, click in the toolbar. Nardog (talk) 08:49, 15 November 2021 (UTC)

Thanks, Nardog, that was it. I did try carefully going through all the things that looked possibly relevant in the toolbar but somehow didn't see that one. —David Eppstein (talk) 17:18, 15 November 2021 (UTC)

There is a vandal IP hopping within a /24 is there a way to search for contribs across all 256 IPs? I could write a quick script but there might be a better tool. -- GreenC 03:29, 14 November 2021 (UTC)

@GreenC: there's a gadget ("Allow /16, /24 and /27 – /32 CIDR ranges..." under Advanced) that adds that functionality to Special:Contributions. Once the gadget is enabled, you can see all the contributions per address by appending /24 to the IP, like Special:Contributions/106.67.34.0/24. clpo13_(talk) 03:46, 14 November 2021 (UTC)

You no longer need the gadget; Special:Contributions supports ranges automatically. Izno (talk) 04:03, 14 November 2021 (UTC)

Cool, exactly what is needed, wish I knew of it years ago. If it's automatic without the gadget, there are no hints on the page for syntax. I initially tried just Special:Contributions/106.67.34.0 -- adding /24 seems obvious now, but wasn't at the time, figured if range was supported it would default to /24 when given a .0 in a Class C. Not that it should do that. Guess some sort of example syntax on the form page could help others know about IP range support because it is super useful when tracking vandals. -- GreenC 04:43, 14 November 2021 (UTC)

Seconded: I find this function very useful but it was hard to discover. Can we replace the "User" prompt by "User, IP or range", or even wikilink a short page about range syntax? Certes (talk) 12:53, 14 November 2021 (UTC)

You can suggest a change to MediaWiki:Sp-contributions-username. BTW the software default is "IP address or username:" – SD0001 (talk) 16:58, 14 November 2021 (UTC)

I've changed it to "Username, IP address or CIDR range" for now. Unfortunately this message is escaped and no wikitext can be used, though it should be simple to fix that in the software, if we really wanted to. — MusikAnimal ^talk 17:40, 15 November 2021 (UTC)

22:05, 15 November 2021 (UTC)

Category:Wikipedians in New York is a redirect to Category:Wikipedians in New York (state) but is being populated by users putting their location into Template:Infobox Wikipedia user which doesn't seem able to cope with the state being disambiguated. Does anyone know how to fix this mess? Timrollpickering (talk) 14:16, 16 November 2021 (UTC)

Perhaps they could specify their location as New York (state) or New York City, depending whether they want to be in Category:Wikipedians in New York (state) or Category:Wikipedians in New York City. Certes (talk) 15:36, 16 November 2021 (UTC)

 Fixed with this edit. There are probably edge cases, but the category is cleared, and the four pages that were in there are in the right category at this time. – Jonesey95 (talk) 16:12, 16 November 2021 (UTC)

Hello! So I attempted to add the ((fyi)) template after I separated 2 different sections on the teahouse, however it appears that something about my sig is preventing the template from showing up properly like this:

FYI

― Blaze The Wolf^Talk_{Blaze Wolf#6545} 15:09, 15 November 2021 (UTC)

@Blaze The Wolf: your signature has a lot of markup that may collide with templates, suggest simplifying it - but as far as this template goes, you can try to declare the paramter as such:

• ((FYI|1=Test. ~~~~)).

That should render as

FYI

 – Test ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 15:09, 15 November 2021 (UTC)

Expect to run in to this problem again, removing the "title" element from your signature may help in many cases. — xaosflux ^Talk 15:37, 15 November 2021 (UTC)

Template:FYI#Usage mentions it. The problem is equals signs in unnamed template parameters being interpreted as parameter assignments. See the second bullet at Help:Template#Usage hints and workarounds. It doesn't happen if the equals sign is inside a wikilink so most signatures with styling avoid it but your current signature will have this issue with many templates. PrimeHunter (talk) 17:43, 15 November 2021 (UTC)

Take note, any of those tips that involve using another template are not appropriate inside a signature, which must not use a template. — xaosflux ^Talk 18:47, 15 November 2021 (UTC)

Ah alright. SO are you saying my signature uses a template? If so I didn't know because I didn't make my signature myself and am willing to remove the template from my signature even if it causes it to not look as nice. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 19:34, 16 November 2021 (UTC)

Nevermind misread what you said. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 19:34, 16 November 2021 (UTC)

I know there was template in PLWP for counting numbers (not just numbering) in table but I don't remember its name and maybe there is other way to achieve it? I remember there was probably two templates one for add all wanted numbers in the table into one template and second template with result. Eurohunter (talk) 20:46, 16 November 2021 (UTC)

Does anyone know why https://reftag.appspot.com/ isn't working anymore and when it might be functioning again? I use it to generate sfns and it's a pain to be without it. Thanks. --Rosiestep (talk) 14:14, 13 November 2021 (UTC)

See previous discussions Wikipedia:Village pump (technical)/Archive 192#doi citation tool down and Wikipedia:User scripts/Requests#restore the Wikipedia Citation Tool for Google Books. There is a replacement for that tool at https://alyw234237.github.io/wiki-doi-gbooks-citation-maker/ – SD0001 (talk) 14:53, 13 November 2021 (UTC)

It doesn't work. I just tried "https://books.google.lu/books/about/Kvinden_k%C3%A6tteren_kunstneren_Karen_Blixe.html?id=453kDwAAQBAJ&redir_esc=y" and "https://books.google.lu/books?id=hn15xB1vMbwC&pg=PT158&lpg=PT158&dq=pligten+dansk+litteratur&source=bl&ots=49fY3KFWmk&sig=ACfU3U1-HWKri7G17t320mnIh-w8Dt8Mjg&hl=de&sa=X&ved=2ahUKEwjUzbr-2JX0AhUYG-wKHRR-Bl0Q6AF6BAgPEAM#v=onepage&q=pligten%20dansk%20litteratur&f=false" and am told they are not valid. They would have worked under the old tool.--Ipigott (talk) 15:53, 13 November 2021 (UTC)

The tool is working when I try with https://www.google.co.uk/books/edition/Primate_Neuroethology/hv28p1tCnnEC?hl=en&gbpv=1&pg=PA15&printsec=frontcover, but I get the same result as you with your link. Perhaps control characters to encode the german ae character is a problem. Regardless, it works for me just with the id 453kDwAAQBAJ. —  Jts1882 | talk 

Did you try using just the google books id? For

• Brundbjerg (453kDwAAQBAJ) I got:

  <ref name="Brundbjerg2020">((cite book | author = Else Brundbjerg | date = 29 May 2020 | title = Kvinden, kætteren, kunstneren Karen Blixen | publisher = Lindhardt og Ringhof | pages = | isbn = 9788726316247 | oclc = 1154625906 | url = https://books.google.com/books?id=453kDwAAQBAJ))</ref>

• Bredsdorff (hn15xB1vMbwC) I got:

  <ref name="Bredsdorff2011">((cite book | author = Thomas Bredsdorff | date = 1 March 2011 | title = Dansk litteratur set fra månen: Om sjælen i digtningen | publisher = Gyldendal A/S | pages = | isbn = 9788702108729 | oclc = 874799050 | url = https://books.google.com/books?id=hn15xB1vMbwC))</ref>

If you can figure out how to do it, you might want to tell the app's author, Alyw234237, about these urls. A quick search did not reveal a way to contact the author but perhaps someone here knows how to do that.

—Trappist the monk (talk) 16:31, 13 November 2021 (UTC)

@Ipigott I'm a bit confused about what kind of citation you're trying to generate. If you have the full URL, you can just use the "Cite" tool built into the editor. It supports autofill – see File:RefToolbar-URL-autofill.png (that screenshot is for web citation but it works for book citation too.) It worked for me for both the URLs you mention. – SD0001 (talk) 16:40, 13 November 2021 (UTC)

Trappist the monk, SD0001: Then the interface, display, or whatever, needs to be improved. I simply followed the instructions and things didn't work. I don't know what you mean by using the Google books ID. I did not have to look for this before. The easy solution would be to restore to old tool which has worked perfectly for years with no problems. Why create new difficulties?--Ipigott (talk) 16:55, 13 November 2021 (UTC)

The old app's author has apparently gone away. Restoring that author's tool is not likely to happen so you are stuck with what we've got. Isn't a tool that does most of what you want with an adjustment to your work-flow better than not having any tool at all?

The google books id is embedded in the google books url. I'm pretty sure that the id is always preceded by ?id=:

https://books.google.lu/books/about/Kvinden_k%C3%A6tteren_kunstneren_Karen_Blixe.html?id=453kDwAAQBAJ&redir_esc=y

—Trappist the monk (talk) 17:07, 13 November 2021 (UTC)

The old tool's author is User:Apoc2400 who is the only one with the ability to restore it. Tools on external domains like that are always maintained by a single user – and can stop working anytime without warning. These difficulties can be avoided by adapting your workflow to use the tools embedded within Wikipedia. The "Cite" tool I mentioned above, 2017 wikitext editor, and VisualEditor can all generate citations from GBooks URLs – I would use one of those. – SD0001 (talk) 17:19, 13 November 2021 (UTC)

SD0001, the Wikipedia DOI and Google Books Citation Maker works fine for me as a citation maker -- as does the "Cite" tool built into editing en.wp. But "Wikipedia DOI and Google Books Citation Maker" doesn't generate sfns, and that's what I'm seeking. --Rosiestep (talk) 18:04, 13 November 2021 (UTC)

I didn't have any trouble getting this app to make citations, but one might as well type them manually, or just input the isbn in the drop down cite tool and let it fill in, because then at least you can fill in the appropriate fields, rather than having to manually type the information. Cite tool still makes errors, but the format is easier to correct fields. Problems with this tool are that it lists authors under the whole name rather than last/first format, making it difficult for proper citation (especially if you are using sfn) and alphabetization, requiring manual adjustments; does not distinguish between editors and authors and in fact, in one link I input added all contributors to the book, no editor at all; author-links must be manually input. And yes, Rosiestep, it doesn't give the sfn link. Format of last|last|last|date|p must be manually typed as well. It isn't as user friendly as the previous tool was. SusunW (talk) 18:06, 17 November 2021 (UTC)

Thanks, SusunW. Indeed, none of the tools are perfect. As for sfns, it seems that we are all stuck with creating them (last|last|last|date|p) by hand these days unless/until reftag.appspot gets fixed. --Rosiestep (talk) 18:12, 17 November 2021 (UTC)

Hello! Would it be interesting to have the "live flow" function that we currently have implemented on the recent changes page also be implemented on user contribution pages? As far as I know, that's not currently possible. You need to continuously keep manually refreshing the page if you want to have the latest contributions show. For me it would be a needed feature when checking bot contributions for different reasons. I thought about asking at Phabricator for such a feature to be implemented but I wanted to have a discussion about it first. - Klein Muçi (talk) 11:13, 17 November 2021 (UTC)

@Klein Muçi: see phab:T234880 to follow development on that feature request. — xaosflux ^Talk 14:02, 17 November 2021 (UTC)

@Xaosflux, oh, it's already being tracked. Okay then. Thank you! :) - Klein Muçi (talk) 18:41, 17 November 2021 (UTC)

To connect via SQL requires two bits of info, for example on enwiki it is database="enwiki_p" and host="enwiki.analytics.db.svc.wikimedia.cloud". What would be the equivalent for https://en.wikipedia.beta.wmflabs.org/ and https://commons.wikimedia.beta.wmflabs.org ? -- GreenC 18:55, 17 November 2021 (UTC)

I don't think databases of those wikis are mirrored to the toolforge replicas. – SD0001 (talk) 03:30, 18 November 2021 (UTC)

It seems that editing an older version of any article is not possible in mobile mode. You do get an edit button[15], but then you get a "view source" page, not an actual editing page[16] (note; I picked a random article here, no need to actually edit this one). Anyone has any idea why this could be the case? Fram (talk) 11:39, 18 November 2021 (UTC)

Hmmm, checking. — xaosflux ^Talk 11:54, 18 November 2021 (UTC)

@Fram: I've opened phab:T295979 on this. Do you know if this ever worked? — xaosflux ^Talk 12:03, 18 November 2021 (UTC)

FWIW, a workaround appears to be to change to the Visual Editor. — xaosflux ^Talk 12:04, 18 November 2021 (UTC)

I'll pass :-) Fram (talk) 12:05, 18 November 2021 (UTC)

No idea, I've only recently started using mobile editing a bit more often (though I still try to avoid it wherever possible). Thank you for checking and starting the phabricator ticket! Fram (talk) 12:05, 18 November 2021 (UTC)

@Fram: apparently this functionality was never built, I've udpated the phab ticket to a feature request. The only workaround right now is do the steps you've done, then pull down the source editor option to the visual editor option while on mobile web in an old version. — xaosflux ^Talk 14:28, 18 November 2021 (UTC)

Or use desktop view even when on mobile, supposedly. Thanks, strange that this doesn't work (hard to imagine a reason for this). Fram (talk) 14:30, 18 November 2021 (UTC)

A module with a protection that is higher than I have does not have a "Preview page with this template" section. This is very useful in testing without needing to edit any live page, while also not causing any protection issues as none of the live module code is modified. Can this be changed? Gonnym (talk) 11:11, 18 November 2021 (UTC)

@Gonnym: this is not currently possible in the software, and a prior request to make it such was declined. You could try to reopen phab:T60515 if there are new arguments. A possible workaround is listed on that task. Most protected templates and modules should have sandbox versions unprotected that you should feel free to test on as well. — xaosflux ^Talk 11:29, 18 November 2021 (UTC)

You can use User:Jackmcbarn/advancedtemplatesandbox.js to preview a page as if the live version had changed while editing the sandbox. * Pppery * _{it has begun...} 19:03, 18 November 2021 (UTC)

Hello!

I sometimes upload files to already created file pages for improvements, updates etc. Because of phab:T38380 I often have to purge the browser cache to make the newly updated version to be displayed. This fixes the problem on both the file page itself and on the artile page where the file is used on. Purging does not however fix the problem on the MediaViewer page. For example purging https://en.wikipedia.org/wiki/File:Tingsryds_AIF_logo.svg#/media/File:Tingsryds_AIF_logo.svg still doesn't make the newly uploaded version to be displayed. Am I purging on the wrong page? Or is it just a bug?Jonteemil (talk) 21:17, 16 November 2021 (UTC)

I had to do a page purge there. Shouldn't be needed normally, but I guess the purge request after the new upload got lost somehow. —TheDJ (talk • contribs) 23:00, 16 November 2021 (UTC)

@TheDJ: What do you mean? My problem is that purging (Ctrl+F5) https://en.wikipedia.org/wiki/File:Tingsryds_AIF_logo.svg#/media/File:Tingsryds_AIF_logo.svg doesn't change the fact that the old version is displayed. Did you manage to purge it?Jonteemil (talk) 00:40, 17 November 2021 (UTC)

@Jonteemil: "Cntrl+F5" is a request to purge your browser's cache, it does not necessarily ask the server to purge it's cache. See WP:PURGE for more information. — xaosflux ^Talk 14:06, 17 November 2021 (UTC)

@Xaosflux: Okay, but how do I make the current version of https://en.wikipedia.org/wiki/File:Tingsryds_AIF_logo.svg#/media/File:Tingsryds_AIF_logo.svg to appear?Jonteemil (talk) 20:44, 18 November 2021 (UTC)

The current version appears for example in Tingsryds AIF. — xaosflux ^Talk 20:52, 18 November 2021 (UTC)

I also opened a private browser, (not logged in), went to that article, clicked the image which opened in MV, and it was also the current. — xaosflux ^Talk 20:54, 18 November 2021 (UTC)

@Xaosflux: I'm no computer expert but for the cache to have stored the old file and MV to show you it instead of the new version I think you have to have seen the file before it was overwritten otherwise how would the cache have stored it? Steps to reproduce: Go to https://commons.wikimedia.org/wiki/File:PNG_Test.png#/media/File:PNG_Test.png, you should right now see a red square here. Go to the file page and revert to the black page which I also uploaded. Go back to https://commons.wikimedia.org/wiki/File:PNG_Test.png#/media/File:PNG_Test.png, do you now see the black page, which you should, or the red page, which you shouldn't. Now on my phone when I do this there is no delay, I see the current file in MV always, I use Safari on iPhone. On my computer however, Windows with Chrome as browser, I see the red square even if I revert to the black one, and I can't purge MV to show the black square, this is my problem. On any page where the file is on the purge (Ctrl+F5) works, so The current version appears for example in Tingsryds AIF is not a problem.Jonteemil (talk) 00:46, 19 November 2021 (UTC)

What's up with search?

My regex searches usually work quite quickly, but in the last few hours I have been getting a lot timeouts on searches such as this one. BrownHairedGirl (talk) • (contribs) 06:56, 19 November 2021 (UTC)

I've never known naked regex searches to work well, and if you've managed it, you might just have been lucky.

I'm not sure why you have the * metaclass on the first > bracket.

Anyway, this search completes within a second or two. It doesn't take a whole lot to get this kind of thing to complete. Izno (talk) 07:24, 19 November 2021 (UTC)

Many thanks, @Izno. I have hacked that search about dozens of times for different URLs, most of which include an optional square bracket before the URL: insource:/\<ref[^\>]*\>\s*\[?\s*https?:\/\/(www\.)?allafrica\.com/

However, where the numbers are big, I do it with and without square bracket ... and it seems that somewhere along the way I missed that stray *. Duh.

It's now working again, well enough for my purposes. BrownHairedGirl (talk) • (contribs) 07:35, 19 November 2021 (UTC)

I recently copied File:Francisc Chassaigne circa 1890.jpg to Commons and deleted the local file. But after realizing that a higher-resolution version already existed at Commons, I requested deletion of my upload and redirected it to the existing one. However, the image now fails to load in one specific revision of the article Francis Chassaigne. It seems to load correctly in all other revisions.

Any idea why this is happening? Ixfd64 (talk) 22:52, 17 November 2021 (UTC)

@Ixfd64: works for me, probably a caching issue on your end. Elli (talk | contribs) 00:13, 18 November 2021 (UTC)

Yeah, it works for me now as well. Somehow the file path to the image did not update in that particular revision. Ixfd64 (talk) 00:32, 18 November 2021 (UTC)

In general, don't rely on foreign repository file redirects - pointing the page at the destination file will give the best results. — xaosflux ^Talk 15:10, 19 November 2021 (UTC)

I've tested hovering the cursor over the FA badge of the Chinese edition link of Jianbing guozi with the new Vector skin with both Microsoft Edge 95.0.1020.53 and Mozilla Firefox 94.0.1 (64-bit) with Windows 10 21H1 Home, discovering that the tooltip is "中文" rather than "featured article badge", which is quite weird and does not make sense at all. When I use Modern or the old Vector, this problem does not happen. There must be a bug in the new Vector skin!--RekishiEJ (talk) 14:18, 19 November 2021 (UTC)

@RekishiEJ: are you having this problem here on the English Wikipedia? If your problem is only on zhwiki, please report at w:zh:Project:互助客栈/技术. — xaosflux ^Talk 14:28, 19 November 2021 (UTC)

@Xaosflux: I'm having this problem on the English Wikipedia.--RekishiEJ (talk) 15:18, 19 November 2021 (UTC)

@RekishiEJ: would you either open a WP:BUG report, or put the step-by-step directions to reproduce the problem here, including what you do see vs what you expect to see, so we can open it for you? — xaosflux ^Talk 15:36, 19 November 2021 (UTC)

Here's how I was able to reproduce the difference between Vector and new Vector: Set your Appearance Preferences to "Vector" skin and select "Use Legacy Vector". Go to Jianbing guozi. On the left side rail, find the links to the article in other languages, and notice that there is a yellow FA star next to "Chinese". Hover your mouse arrow over the star, and you should see "featured article badge" as a tooltip. Now go to Appearance Preferences, uncheck "Use Legacy Vector", and reload Jianbing guozi. Go to the Languages menu at the upper right, pop it down, and notice a yellow FA star next to "Chinese". Hover over the star, and the tooltip says "Chinese". (Note: I think I have another gadget, "SidebarTranslate: display sidebar language links in English", selected that makes the languages appear in English, so I see "Chinese" instead of "中文" in the tooltip, but the difference is still there). – Jonesey95 (talk) 17:31, 19 November 2021 (UTC)

I have edited with Android smartphones on the desktop site for many years. Currently, I use a Samsung Galaxy S21 Ultra 5G which I have had for several months. Suddenly about 24 hours ago, the back arrow at the bottom of the screen disappeared, and that makes navigation much more complicated. How can I get my back arrow back? I tried restoring to the default settings but that did not work. Any ideas? Cullen328 (talk) 00:23, 22 November 2021 (UTC)

I restarted my phone and that solved the problem. Cullen328 (talk) 01:17, 22 November 2021 (UTC)

Does anyone know why MediaWiki default (a system account controlled by the developers) created Category:Computer storage stubs in 2005? * Pppery * _{it has begun...} 03:06, 22 November 2021 (UTC)

Well at that time Wikipedia was being upgraded to MediaWiki 1.5, which was quite an undertaking, as I well remember. That article I just linked says that Wikipedia wasn't fully up until a few hours later, so the upgrade probably caused the problem here. Graham87 05:30, 22 November 2021 (UTC)

I didn't even know about this page until searching through Wikipedia:Village pump (technical)/Archive F, but there was an old page called MediaWiki 1.5 bugs, on which this was reported (see the section "Mystery history"), which also links to what is now T4559. Graham87 05:38, 22 November 2021 (UTC)

After looking into this a bit further (and properly reading the bug report, I found that almost all of these edidts had indeed been deleted, as the bug report said; this can be seen in the deleted main namespace edits (admin only). The ones that were visible to non-admins had been undeleted later, so I'd gone and redeleted them, including the example above. This can be verified by checking the edits by MediaWiki default that are not in the MediaWiki namespace. Graham87 16:47, 22 November 2021 (UTC)