Wikipedia:Village pump (technical)

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

view · edit

Frequently asked questions (see also: Wikipedia:FAQ/Technical)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Lockout script misbehaving

I have a forked version of User:Anomie/lockout.js in my common.js which only blocks editing, not viewing. However, if the edit page is opened by DraftCleaner, the edit page isn't blocked and I can edit as usual, including if other scripts refresh the page. Why does this happen, and is there a way to block the edit page in this case? Suntooooth, it/he (talk/contribs) 03:31, 19 November 2024 (UTC)[reply]

Suntooooth, that's because DraftCleaner uses ?action=submit to open the editor, while your lockout script only checks for ?action=edit. You could change the condition of the if-statement to something like !["edit", "submit"].includes(mw.config.get("wgAction")). Rummskartoffel 21:21, 23 November 2024 (UTC)[reply]

I'll try that out, thank you! :] Suntooooth, it/he (talk/contribs) 18:46, 24 November 2024 (UTC)[reply]

Proposed change to tabs on redirect pages

I am proposing in phab:T5324#10347051 that the page tabs on redirect pages (‘Article/Talk’ and ‘View’ depending on the page) get a small improvement: they would link to redirect pages themselves by default. Currently they link to their targets with a possibility of navigating back. The change should improve navigation from other actions, like going from history page for "WOW" redirect to the redirect page itself. This should be especially beneficial for English Wikipedia since this community has a system of redirect templates. You would still be able to navigate to redirect target, just with an additional click.

Please let me know either here or on Phabricator (by awarding a token or leaving a comment there) if you are for, against or indifferent to this potential change. It was previously announced in Tech News in 2020 but no one went on to actually review the change. Hopefully this time would be different. stjn 01:24, 22 November 2024 (UTC)[reply]

Unsurprisingly, I agree with the change, having reopened the Phabricator task in 2019. I was using this one-liner to mitigate for a while.

The talk page behavior is likely more contentious: essentially this turns talk page redirects into soft redirects when clicking on the 'Talk' tab, which is probably the most common way of accessing them. Numerous closely-related templates use redirects to centralize discussion (example: Template talk:Cite news and related templates). Bot talk pages often redirect to the bot operator's talk page (5/10 of the top 10 active bots by edits do this: 1, 2, 3, 4, 5). Also in Wikipedia namespace you can find cases like AN and ANI that have a merged talk. Retro (talk | contribs) 06:56, 22 November 2024 (UTC)[reply]

Those are all cases where a normal page has a redirected talk page. I think the proposed change would only apply to redirects with redirected talk pages. jlwoodwa (talk) 07:32, 22 November 2024 (UTC)[reply]

Yeah, if that's the case, there's no issue. Retro (talk | contribs) 07:52, 22 November 2024 (UTC)[reply]

If I understood correctly even in the case of going from a redirected article to a redirected talk page it would go to the target of the redirected talk page. The change as I understood would be:

When going from history, info,... of a redirected article to the article itself it would stay in the redirect
When going from history, info,... of a redirected talk page to the talk itself it would stay in the redirect

Going from a redirected article to the redirected talk page would still behave as it does now. -- Agabi10 (talk) 09:07, 22 November 2024 (UTC)[reply]

Looking at the current version (Patchset 2) of gerrit:r/1094077, your second bullet is not correct. The behavior is simpler:

The talk tab would still follow the redirect, except when the talk tab is the current tab (e.g. you're already on the talk page with &redirect=no, or viewing the talk page history).
The subject tab would always stay in the redirect.
Extra tabs, such as TimedText on Commons or Source on Wikisource, will work similarly: stay on redirect if pointing to a subject namespace or are the current tab, follow redirect if pointing to a talk namespace and non-current.

Personally, I'm not so sure of this behavior change. When I'm already at a &redirect=no, I tend to click on the tab to follow the redirect. Clicking the link in the "soft-redirect" on the redirect=no page has different behavior in some edge cases (e.g. double redirects) and won't show the "redirected from" on the target page. OTOH, it's better than the more-consistent alternative that Retro was concerned about above, which would have made it much more likely for people to start commenting on redirected talk pages. Anomie ⚔ 13:01, 22 November 2024 (UTC)[reply]

The current Gerrit patchset is a first attempt at implementing this. It should not be referenced as what I want to achieve. Ideally, only the tabs related to the currently viewed page would have redirect=no added. So TimedText/Source etc. should only be affected when they are the current page and user is viewing something related to the redirect.

Currently, there is no way to get to view the redirect page in one click even if you are on edit/history pages. That is more unacceptable than someone being a bit inconvenienced by having to click to the big article name and not the tab. stjn 13:23, 22 November 2024 (UTC)[reply]

How often do people really need to get to view the redirect page that one click rather than two for this use case outweighs the drawbacks of increasing the inconsistency of the UI and requiring editing the URL to follow the redirect as a reader would? Anomie ⚔ 13:11, 23 November 2024 (UTC)[reply]

‘Increasing inconsistency’ is your personal opinion that multiple people already disagreed with. In my opinion, it would decrease the inconsistency, as all the other page tabs relate and point to the current page, and not to the redirect target, so the main ones should, too. Currently people are already required to edit the URL, just in the other direction. stjn 14:32, 23 November 2024 (UTC)[reply]

The inconsistency I referred to is that, with your proposed change, the tab will sometimes follow the redirect and sometimes not. PS6 seems intended to make it more sometimes-and-sometimes-not. As for URL editing, people don't have to edit the URL to get to the redirect page now, but they do need two clicks: one on the tab, following the redirect, and then one the "Redirected from" under the page title to get to the redirect itself. Anomie ⚔ 23:59, 23 November 2024 (UTC)[reply]

When I started on Wikipedia, waaaay back in May 2009, if you clicked on a link for a redirect, the redirection would occur client-side and your browsing history would get two entries: one for the redirect page, and one for where you got redirected to. An effect of this was that you needed to use the browser's "back" feature twice in order to return to where you first came from. A bonus side effect was that if you only used "back" once, you could then work on the redirect page directly - "edit", "history", etc., even "move" if you were that silly. Nowadays the redirection is performed server-side, which in some ways makes it harder. --Redrose64 🌹 (talk) 00:31, 24 November 2024 (UTC)[reply]

The tab will follow the redirect when you are not looking at the redirect page and won’t when you are. That is not inconsistent.

The workflow you described in the last sentence can also be described as requiring people to edit the URL to get to the redirect page, since it is much easier to copy the URL and then add ?redirect=no than it is to aim at the barely visible ‘Redirected from’ notice (especially for section redirects, which do not show it at all, see phab:T360255 / phab:T169282). stjn 21:19, 24 November 2024 (UTC)[reply]

Section redirects do show it, they're in the usual place below the page title. You just have to hit the Home key, that's all. --Redrose64 🌹 (talk) 22:46, 24 November 2024 (UTC)[reply]

Gerrit patch was improved to not affect the non-current or extra tabs. stjn 15:41, 22 November 2024 (UTC)[reply]

I only mean that if someone is on the redirect talk page, they should be able to navigate to it from ‘Talk’ tab. Otherwise (‘Talk’ page on non-talk pages) there should be no change. stjn 12:42, 22 November 2024 (UTC)[reply]

My initial thought is that this seems fine, since it'll only affect editors (readers have basically no reason to end up at a redirect page). But overall we should be careful not to focus unduly on our editing needs over their reading needs. Sdkb ^talk 17:04, 22 November 2024 (UTC)[reply]

I'm confused about what is being proposed here, so I'll just say that if the URL of the page I'm viewing includes "redirect=no" then I want that to be preserved when I click the article or talk tabs. When I'm viewing the non-redirected talk page of a redirect and click the article tab I could be wanting either the reidrect or its target, probably the former about two thirds to three quarters of the time, but as someone who does a lot of work with redirects I don't know how typical my workflow is. Thryduulf (talk) 13:55, 23 November 2024 (UTC)[reply]

Mobile wikipedia images problem

Images on the sides of articles don't show up with Javscript disabled on en.m.wikipedia.org, only their captions. Images in the infobox and the main page load normally. If you don't want to show images in articles to users who disable Javascript in Firefox please remove the captions too so there's no clutter. 31.217.45.191 (talk) 14:34, 22 November 2024 (UTC)[reply]

It works for me with Firefox 132.0.2 (64-bit) on Windows 10, JavaScript disabled, both logged in and out. For example, I see File:SN1998aq max spectra.svg at Type Ia supernova#Consensus model. Do you see the image on the article? On the file page? At https://upload.wikimedia.org/wikipedia/commons/2/25/SN1998aq_max_spectra.svg? If you see it on the article then please give an example you don't see. PrimeHunter (talk) 16:21, 22 November 2024 (UTC)[reply]

My bad, I accidentally disabled <noscript> tags too in my browser. Sorry 31.217.45.191 (talk) 19:35, 22 November 2024 (UTC)[reply]

Electcom seeks technical assistance

Resolved

– Thank you everybody for your input. I think we've got this resolved now. RoySmith (talk) 16:00, 23 November 2024 (UTC)[reply]

In dealing with an issue, electcom implemented Special:Diff/1258984383 which unfortunately broke the question numbering. I'd appreciate any suggestions on what wikimarkup could be used to keep the hatted text hatted and also preserve the question numbering sequence. RoySmith (talk) 00:19, 23 November 2024 (UTC)[reply]

Is this still a problem? I see the question numbers, including the collapsed one at question 21. If still an issue, please describe the problem a bit more. — xaosflux ^Talk 00:38, 23 November 2024 (UTC)[reply]

Try uncollapsing the text, and then try adding a new question beneath the old one. Izno (talk) 00:41, 23 November 2024 (UTC)[reply]

{{ACE Question}} is implemented in a way which makes this practically impossible without something in the hatted text looking off if you collapse things. It basically assumes the structure of the container (an ordered list) and then indents the answer with wikitext #:. That is a flaw of that template that cannot be corrected without some non-0 study. Izno (talk) 00:41, 23 November 2024 (UTC)[reply]

Not only that, but {{hab}} only works if it's added at a new line, which would break the numbering either way.

~~The way it is currently~~ the hat just swallows new questions, the hab having no effect. – 2804:F1...86:EF41 (::/32) (talk) 03:01, 23 November 2024 (UTC)[reply]

The easy answer is just to remove the text instead of collapsing it. —Cryptic 00:45, 23 November 2024 (UTC)[reply]

OK, thank you all for the assistance. We'll put our heads together off-wiki and figure out a plan. RoySmith (talk) 00:50, 23 November 2024 (UTC)[reply]

You could create a wrapper div for the questions after 21 with a special class name, then create a style sheet (using Wikipedia:TemplateStyles) that sets the starting number of the ordered list within that div. isaacl (talk) 01:52, 23 November 2024 (UTC)[reply]

More kludgily, since the list would be the second ordered list in the content area, the corresponding style sheet rule could be written to target the second ordered list. That would avoid the need for a wrapper div. isaacl (talk) 02:00, 23 November 2024 (UTC)[reply]

The style rule would be something like the following:

.mw-body-content ol:nth-of-type(2) li:nth-of-type(1)
{
  counter-set: list-item 22;
}

isaacl (talk) 02:45, 23 November 2024 (UTC)[reply]

@Isaacl: You don't need to go to those lengths. Ordered lists can be fudged directly, check this out:

Here is a list:
#This is the first item
#Second item
#<li value=4>Not the third item
#List continues
with text after.

It's demonstrated at WP:Sandbox. --Redrose64 🌹 (talk) 14:49, 23 November 2024 (UTC)[reply]

From an accessibility point of view, is any other choice other than replacing with text (maybe with a permalink if you want it to be accessible) even good?

The only thing I found that sorta works is wrapping it all in a {{efn|1= ... }}, but then you have to add a notelist somewhere where the question will actually appear (collapse and all). That doesn't break the numbering of the questions afterwards. – 2804:F1...86:EF41 (::/32) (talk) 03:40, 23 November 2024 (UTC)[reply]

@RoySmith: To be honest, I don't think it needs a complicated technical response. ARBPIA states that this restriction may be enforced by other methods, including ... reverts, and that applies On any page where the restriction is not enforced through ECP. So you can just get rid of it, much easier. SerialNumber54129 15:34, 23 November 2024 (UTC)[reply]
Thank you for unboxing, Redrose64. It was bloody uncivil of RoySmith to shut it off in the first place. SerialNumber54129 20:52, 23 November 2024 (UTC)[reply]
I didn't mean to be uncivil. I had the answers I needed, that was all. If folks want to continue to chat about this, please feel free to do so. RoySmith (talk) 21:15, 23 November 2024 (UTC)[reply]

Article incorrectly marked as List class

I noticed that the article Femke is wrongly marked as List class on the talk page, where it should have been marked as GA class, like I believe it was previously, but now the class in the banner shell appears to be overridden. I suspect that this is somehow caused by / related to the {{given name}} template, despite the section=y parameter that indicates only one section and not the whole article contains a list of given names. Could this be fixed? – Editør (talk) 09:21, 23 November 2024 (UTC)[reply]

@Editør: This is due to recent changes at Module:Banner shell. You should see if there's anything on the matter at Template talk:WikiProject banner shell. If there isn't, raise a thread on that page and and notify MSGJ (talk · contribs) when doing so. --Redrose64 🌹 (talk) 14:16, 23 November 2024 (UTC)[reply]

Thanks. I couldn't find this topic on the talk page, so I added it as advised. – Editør (talk) 17:17, 23 November 2024 (UTC)[reply]

The first sentence of that template says Template:given name is only for use on Wikipedia set index articles. If Femke isn't a set index article, then that template shouldn't be used there. Misusing templates can and usually does, break other things. Remove the template from that page and the banner should work. Gonnym (talk) 14:49, 24 November 2024 (UTC)[reply]

Thank you for your comment, I've replied here. – Editør (talk) 18:24, 24 November 2024 (UTC)[reply]

Concern involving User:MusikBot II/TemplateProtector

Moved to User talk:MusikAnimal

JJP_{Mas_ter} (she/they) 19:49, 23 November 2024 (UTC)[reply]

Problems with WP:Twinkle

Moved to Wikipedia talk:Twinkle § Problems with WP:Twinkle

– – SD0001 (talk) 16:56, 24 November 2024 (UTC)[reply]

Discussion at Wikipedia talk:Editnotice § adding a backlink to edit notices

You are invited to join the discussion at Wikipedia talk:Editnotice § adding a backlink to edit notices. Sdkb ^talk 06:23, 25 November 2024 (UTC)[reply]

Revision slider missing?

I am not sure if I changed something, but I've checked my common.js and preferences ("Don't show the revision slider" not checked) but the revision slider ("Browse history interactively") is not showing. Did I do something wrong or is it disabled? </MarkiPoli> <talk /><cont /> 11:38, 25 November 2024 (UTC)[reply]

Oh, it seems to be only on diff pages, not the "old revision" pages.</MarkiPoli> <talk /><cont /> 11:44, 25 November 2024 (UTC)[reply]

RevDel Error Message

I'm noticing a very unusual error, when I compare diffs between a deleted revision LTA and a live revision, it won't show, obviously, because I'm not an admin, but then it also pops up the following in a red box:

User doesn't have access to the requested revision (The revision #1259514017 belongs to a deleted page. You can [//wiki.riteme.site/w/index.php?title=Special:Undelete&target=Wikipedia:Help_desk×tamp=20241125161251&diff=prev view it]; details can be found in the [//wiki.riteme.site/w/index.php?title=Special:Log/delete&page=Wikipedia:Help_desk deletion log].).

(I've nowikied the above, because the error box literally shows that).

MediaWiki:Rest-permission-denied-revision would be the closest match to the error, I think. Myrealnamm's Alternate Account (talk) 16:40, 25 November 2024 (UTC)[reply]

For reference, this is the diff: [1]

I can reproduce the problem, it seems to be caused by trying to display a visual diff, which neither you nor I can view. I found a similar bug report at T337817, although the error message has apparently changed since 2023. Matma Rex talk 16:57, 25 November 2024 (UTC)[reply]

Huh. I remember clearly that days ago, perhaps weeks, the error message was still "Invalid response from server", like desribed at phab.

If you go to a random diff, like this one: Special:Diff/1259521939, and you select Visual Editor, then go to [2], the error will show. If you go back to Special:Diff/1259521939, and select source editor, then if you return to [3] and reload the page, the error will not show. Myrealnamm's Alternate Account (talk) 17:05, 25 November 2024 (UTC)[reply]

Drafts dashboard

I saw a discussion about a useful-sounding Drafts dashboard . The link is a 404: https://ee-dashboard.wmflabs.org/dashboards/enwiki-metrics#pages-graphs-tab . Does anyone know what happened to it? Cheers and thanks, Clayoquot (talk | contribs) 17:47, 25 November 2024 (UTC)[reply]

The wikitech:EE Dashboard seems to have been closed about 10 year ago. — xaosflux ^Talk 21:41, 25 November 2024 (UTC)[reply]

Thanks. I checked a few URLs on the Wayback Machine and can't find anything archived either. Whatamidoing (WMF) do you know any way to get this resurrected? Clayoquot (talk | contribs) 23:22, 25 November 2024 (UTC)[reply]

You could try asking over at mw:Talk:Editing team. — xaosflux ^Talk 11:37, 26 November 2024 (UTC)[reply]

Tech News: 2024-48

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

Updates for editors

A new version of the standard wikitext editor-mode syntax highlighter will be available as a beta feature later this week. This brings many new features and bug fixes, including right-to-left support, template folding, autocompletion, and an improved search panel. You can learn more on the help page.
The 2010 wikitext editor now supports common keyboard shortcuts such Ctrl+B for bold and Ctrl+I for italics. A full list of all six shortcuts is available. Thanks to SD0001 for this improvement. [3]
Starting November 28, Flow/Structured Discussions pages will be automatically archived and set to read-only at the following wikis: bswiki, elwiki, euwiki, fawiki, fiwiki, frwikiquote, frwikisource, frwikiversity, frwikivoyage, idwiki, lvwiki, plwiki, ptwiki, urwiki, viwikisource, zhwikisource. This is done as part of StructuredDiscussions deprecation work. If you need any assistance to archive your page in advance, please contact Trizek (WMF).
View all 25 community-submitted tasks that were resolved last week. For example, a user creating a new AbuseFilter can now only set the filter to "protected" if it includes a protected variable.

Updates for technical contributors

The CodeEditor, which can be used in JavaScript, CSS, JSON, and Lua pages, now offers live autocompletion. Thanks to SD0001 for this improvement. The feature can be temporarily disabled on a page by pressing Ctrl+, and un-selecting "Live Autocompletion".
Tool-maintainers who use the Graphite system for tracking metrics, need to migrate to the newer Prometheus system. They can check this dashboard and the list in the Description of the task T350592 to see if their tools are listed, and they should claim metrics and dashboards connected to their tools. They can then disable or migrate all existing metrics by following the instructions in the task. The Graphite service will become read-only in April. [4]
The New PreProcessor parser performance report has been fixed to give an accurate count for the number of Wikibase entities accessed. It had previously been resetting after 400 entities. [5]

Meetings and events

A Language community meeting will take place November 29 at 16:00 UTC. There will be presentations on topics like developing language keyboards, the creation of the Mooré Wikipedia, the language support track at Wiki Indaba, and a report from the Wayuunaiki community on their experiences with the Incubator and as a new community over the last 3 years. This meeting will be in English and will also have Spanish interpretation.

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

MediaWiki message delivery 22:39, 25 November 2024 (UTC)[reply]

Extra letter "R" between C and D in category listing

See Category:All portals. The list first shows portals starting with 0-9, then starting with A, B, C (including things not starting with C, but with a sortkey starting with a C), then continues through the alphabet with R, D, E, ..., P, Q, R, S, ... What is this extra letter "R" between C and D?

The issue was reported by User:JoeNMLC at Wikipedia_talk:WikiProject_Portals#Curious_about_"Portal_category_list" but this looks like it could use some wider attention. —Kusma (talk) 11:00, 26 November 2024 (UTC)[reply]

Fixed with forcing update of the category member by removing/readding to the category. — xaosflux ^Talk 11:33, 26 November 2024 (UTC)[reply]

Thanks! So it was some kind of database hiccup? —Kusma (talk) 11:58, 26 November 2024 (UTC)[reply]

It looks like a hiccup or MediaWiki bug I haven't seen before. The Internet Archive shows [6] the issue 19 September with an R heading between the C and D headings. Special:ExpandTemplates shows Portal:Reformed Christianity just adds a normal [[Category:All portals]] with no sortkey and no DEFAULTSORT. It's added by a template but even if the template had different code at the time, it should not be possible to create an R heading between C and D on a category page. The Internet Archive shows a normal Latin letter R and not some special Unicode character. PrimeHunter (talk) 12:11, 26 November 2024 (UTC)[reply]

Here is HTML source from the Internet Archive:

<li><a href="/web/20240919122212/https://wiki.riteme.site/wiki/Portal:Czech_Republic" title="Portal:Czech Republic">Portal:Czech Republic</a></li></ul></div><div class="mw-category-group"><h3>R</h3>
<ul><li><a href="/web/20240919122212/https://wiki.riteme.site/wiki/Portal:Reformed_Christianity" title="Portal:Reformed Christianity">Portal:Reformed Christianity</a></li></ul></div><div class="mw-category-group"><h3>D</h3>
<ul><li><a href="/web/20240919122212/https://wiki.riteme.site/wiki/Portal:Delaware" title="Portal:Delaware">Portal:Delaware</a></li>

It looks as you would expect if R was actually a letter betwen C and D and there was only one portal starting with R. The category collation system determining how to sort characters is sometimes changed and can be set differently for different wikis. Maybe this page was cached in the middle of a change or accidental setting. PrimeHunter (talk) 12:23, 26 November 2024 (UTC)[reply]

Standard parameter name for Wikidata IDs

I now find that we have a number of parameter names for a Wikidata item about a subject, for example:

{{Authority control}} - |qid=
{{Interlanguage link}} - |WD=
{{Taxonbar}} - |from=

This causes confusion for editors who use more than one of these templates, on a regular or occasional basis.

I propose that we standardise these to |qid=, while keeping existing names as aliases for backwards compatibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:44, 26 November 2024 (UTC)[reply]

We also standardized on |coordinates= in infoboxes a few years ago, which was a nice improvement. |qid= makes the most sense to me for this purpose. I get 227 hits in template space for {qid|, only 10 hits for {WD|, and 66 hits for {from| (most of which are not Wikidata-related). – Jonesey95 (talk) 17:08, 26 November 2024 (UTC)[reply]

Batch reversion of edits by a single user

(Note: Sorry, if this is a FAQ. Just provide the link and I'll be on my way.)

Does Wikipedia provide some means of reverting several edits by a single user in one go? As a concrete example, I cite the instance of the following user:

https://wiki.riteme.site/wiki/Special:Contributions/Estradadarwin15

The user appears to have made several edits within the span of a few days designed to assert or to falsely establish as fact that a number of large multinational drug companies are subsidiaries of a small privately held Philippine drug company.

Here's one particular instance:

https://wiki.riteme.site/w/index.php?title=Hisamitsu_Pharmaceutical&oldid=1259299932

One of his edits (URL below) appear to have been reverted but there are at least three more.

https://wiki.riteme.site/w/index.php?title=Pfizer&oldid=1259300235 MeshLearning (talk) 17:19, 26 November 2024 (UTC)[reply]

MeshLearning, try User:Writ Keeper/Scripts/massRollback or Wikipedia:Kill-It-With-Fire. — Qwerfjkl talk 17:26, 26 November 2024 (UTC)[reply]

Most common language tags and TemplateData suggested values capacity

I'm wondering if there is a way to produce a list of the most frequently used IETF BCP 47 language tags in use on English Wikipedia. By "in use", I mean values for the HTML lang attribute in current published articles. Such a list would be useful so that we could populate the TemplateData suggested values of the many templates that have a language parameter with the values that editors are most likely to use. To be clear, I mean the full language tags with subtags, and not just the language code.

I'd also welcome guidance on how many suggested values is advisable for usability purposes. Instead of using most common values, I could include the 183 ISO 639-1 codes. Is that too many? Daask (talk) 23:00, 26 November 2024 (UTC)[reply]

I was expecting the answer would be to do a search on the HTML output of English Wikipedia, but I see that the subcategories of Category:Articles containing non-English-language text are fairly detailed and include at least some subtags. I suppose an answer could be produced by finding the largest of these subcategories and then converting them from names back to language tags (probably with the same Module:Lang that populates them). I'm not sure how to do that. Daask (talk) 23:17, 26 November 2024 (UTC)[reply]

Watchlist

Resolved

Today I've been getting many articles regarding Uganda popping up on my watchlist, I have no idea how these articles got on my list, is there something (like compromising whatchlist) going on. I keep a copy of my list in notepad++, I just copied my backup to my list, and the first thing to po up was a Ugandan article. I guess I just asking if there a know issue. - FlightTime (open channel) 01:02, 27 November 2024 (UTC)[reply]

Are they articles you have edited? — xaosflux ^Talk 02:21, 27 November 2024 (UTC)[reply]

If so, check your settings in Special:Preferences#mw-prefsection-watchlist to see if "add pages I ...." are set where you don't want it to be. — xaosflux ^Talk 02:29, 27 November 2024 (UTC)[reply]

Could it be that you edited a template they use? Johnbod (talk) 02:55, 27 November 2024 (UTC)[reply]

I've already checked those, thanx for your responses, I'll just weed them out as they come up. Cheers, - FlightTime (open channel) 06:41, 27 November 2024 (UTC)[reply]

Non-free image uploaded to Wikipedia claims to be hosted on commons

This is kind of a strange issue. I uploaded File:Katana Engine Material Editor.png using Wikipedia:File upload wizard's non-free image form and gave a rationale and now the rationale is gone. I used the software screenshot template. And when I click on "Create source" I get a dialog saying

"This media file is on Wikimedia Commons—not on the English Wikipedia. Descriptions should be placed there. This page should rarely be used except to indicate featured pictures. Please see the description page on Commons for file information, a list of pages that use this file, or the direct link to this file."

Yet commons:File:Katana Engine Material Editor.png does not show anything at all and says "No file by this name exists." I gave the basic points of rationale in File talk:Katana Engine Material Editor.png. I'm wondering what happened here and how to fix it. J2UDY7r00CRjH (talk) 02:09, 27 November 2024 (UTC)[reply]

@J2UDY7r00CRjH that edit notice is in error, we will need to look in to that. In the meantime, just ignore it and update your file description directly. — xaosflux ^Talk 02:21, 27 November 2024 (UTC)[reply]

It looks like that edit message comes if the local description page doesn't exist, even if the file is local. I created a blank page for that file for now, please be sure to update it with licensing information. — xaosflux ^Talk 02:28, 27 November 2024 (UTC)[reply]

Thanks for letting me know. Worth noting there may be two errors: one that causes the rationale to not be added to the page and another that gives that notice pointing to a commons page that does not exist. Although more likely is that there is a single root cause. J2UDY7r00CRjH (talk) 02:28, 27 November 2024 (UTC)[reply]

Why solidpixels.com is blocked?

If adding references to websites, which were created by solidpixels.com, Citoid adds to the reference also solidpixels URL and ends up with the following message "This site is blocked". Why that website is blocked, and is it at Wikimedia blacklist or Zotero black list? The reference links to try are:

https://www.dox.cz/program/daniel-pesta-determination

https://www.resite.org/speakers/mirik-milan

```
https://www.visitbanat.com/srbsko
```

Note:

If I tried to add here an external url as an example, there was this error message: "People at this wiki decided to block links to this site. Please try another link"
If I add here the above links as plain links I got the following error: "Your edit was not saved because it contains a new external link to a site registered on Wikipedia's blacklist or Wikimedia's global blacklist." But nor
```
dox.cz
```
neither
```
solidpixels.cz
```
are listed on those black lists

Juandev (talk) 14:54, 27 November 2024 (UTC)[reply]

@Juandev: Links to dox.cz are blocked by \bdox\.\w{2,5}\ at meta:Spam blacklist. The other links are allowed. The HTML source of https://www.dox.cz/program/daniel-pesta-determination says <meta name="author" content="solidpixels., https://www.solidpixels.com" />. That's why Citoid places https://www.solidpixels.com in an author parameter. It's not the cause of the block. https://www.solidpixels.com is allowed. PrimeHunter (talk) 17:08, 27 November 2024 (UTC)[reply]