Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
 Policy Technical Proposals Idea lab WMF Miscellaneous 
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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


Infobox settlement[edit]

As a person who regularly works with categorization cleanup, I've noticed a recurring problem that I wanted to ask if anybody can solve.

What happens, over and over again, is that somebody adds a {{citation needed}} tag for the population of a community that's using {{Infobox settlement}} without explicitly referencing the population there — but because they frequently pop the tag directly onto the population number in population_total = instead of placing it in the population_footnotes = field where it really belongs, the automatic comma-delimiter function in population_total automatically also comma-delimits the year in the citation tag's transcluded maintenance category, resulting in Special:WantedCategories constantly getting cluttered up with nonsense categories like Category:Articles with unsourced statements from June 2,022 (note the comma in the year) where it really should have been Category:Articles with unsourced statements from June 2022.

But this obviously isn't a thing that those of us who work on category cleanup should be expected to just put up with repeatedly mopping up over and over again — it's a thing that by rights we should never be seeing at all, because it should be flatly impossible for the template to even be able to cause such a nonsense category to get generated in the first place. WP:TEMPLATECAT even explicitly states that "When templates are used to populate administration categories, ensure that the code cannot generate nonsensical or non-existent categories, particularly when the category name depends on a parameter".

Obviously we don't want to completely shut off comma-delimiting in that field, because it's necessary in the population numbers themselves, but is there any way that some sort of "firewall" can be coded so that it can continue to comma-delimit the population numbers while simultaneously being prevented from fucking up the maintenance category if somebody places the citation tag in the wrong field? Bearcat (talk) 18:46, 17 June 2022 (UTC)[reply]

If cn is particularly common, you could add some Module:String based code to remove a citation needed after display but before categorization. Izno (talk) 19:00, 17 June 2022 (UTC)[reply]
I don't know how to do that, which is precisely why I'm asking for help. Bearcat (talk) 01:56, 18 June 2022 (UTC)[reply]
@Bearcat, something like:
{{#invoke:String|replace|source={{subst:cn}}|pattern=%[%[Category:All articles with unsourced statements%]%]%[%[Category:Articles with unsourced statements from .+?%]%]%<sup class="noprint Inline-Template Template-Fact" style="white-space:nowrap;"%>%[%<i%>%[%[Wikipedia:Citation needed%{{!}}%<span title="This claim needs references to reliable sources%. %(.+?%)"%>citation needed%<%/span%>%]%]%<%/i%>%]%<%/sup%>|plain=false|replace=}}

(though there's some error as this doesn't work). ― Qwerfjkltalk 07:36, 18 June 2022 (UTC)[reply]
So you're giving me broken code that doesn't work in the first place, and even if it did work I still wouldn't have the foggiest notion what I was actually supposed to do with it anyway? I asked for somebody who knows how to fix this to just fix it, not for half-baked advice on fixing it myself. Bearcat (talk) 12:09, 22 June 2022 (UTC)[reply]
@Bearcat, This code does work:
{{#invoke:String|replace|source={{{population_total|}}}|pattern=%[%[Category:All articles with unsourced statements%]%]%[%[Category:Articles with unsourced statements from %a+ %d+%]%]%<sup class="noprint Inline%-Template Template%-Fact" style="white%-space:nowrap;"%>%&#91;%<i%>%[%[Wikipedia:Citation needed%{{!}}%<span title="This claim needs references to reliable sources%.%&#32;%(%a+ %d+%)"%>citation needed%<%/span%>%]%]%<%/i%>%&#93;%<%/sup%>|plain=false|replace=}}

This should return the parameter without any citation needed tags. (It only took me an hour, too.) I would fix it myself, but I'm not a template editor, nor do I have the energy to make an edit request. Sorry. ― Qwerfjkltalk 15:18, 22 June 2022 (UTC)[reply]

Help to reset a password?[edit]

A long-time editor I know (since '02!) who took a break for many years, now needs a password reset. They didn't set an email in user prefs, but list their email on their userpage. Is emailing ca@ still the right way to ask a dev to set the email for the account? – SJ + 20:41, 17 June 2022 (UTC)[reply]

@Sj: They (or you) can file a task on Phabricator. If they can prove that the account belongs to them, devs will likely act. NguoiDungKhongDinhDanh 01:51, 18 June 2022 (UTC)[reply]
@Sj: yes, emailing ca@ is the best way, especially if you can vouch for them being the legitimate account owner. Legoktm (talk) 05:10, 18 June 2022 (UTC)[reply]
File a task and reference it through ca@. 🐶 EpicPupper (he/him | talk) 05:11, 18 June 2022 (UTC)[reply]
Email ca@wikimedia.org. Trisbendo (talk) 14:02, 18 June 2022 (UTC)[reply]
The "right way" is just start a new account. A dev or wmf MAY help, but they may not. — xaosflux Talk 16:54, 18 June 2022 (UTC)[reply]
The devs will require absolute evidence that the long-time editor concerned really is the same person that was using the login ID concerned. As noted by Xaosflux, it's much easier for the long-time editor to just create a new account. My advice is that an early (if not the first) edit of that new account should be to create a user page stating something like "This user has previously edited under the name of (insert previous login ID) but lost their password". That makes it plain that sockpuppetry is not involved. Also, get them to set that email address. --Redrose64 🌹 (talk) 21:11, 18 June 2022 (UTC)[reply]
I would think the edit history of their user page showing that they listed their email on their user page should be evidence enough that that editor owns that email address. --Ahecht (TALK
PAGE
) 14:14, 21 June 2022 (UTC)[reply]
Not everybody puts their email address on their user page. I certainly don't. --Redrose64 🌹 (talk) 05:53, 22 June 2022 (UTC)[reply]

Saving edits in AWB like Huggle[edit]

I am thinking, why cannot we save edits using AWB like we do in Huggle. Let me be clear. In huggle, we perform certain operations one by one, and all of them are left in a queue, and huggle performs them one by one. We don't have to wait for Huggle to perform the edits. But in AWB we have to wait until AWB saves the edit and then a new page appears. What are the problems that can happen if AWB was configured like Huggle and it also had a edit queue? Itcouldbepossible Talk 04:31, 19 June 2022 (UTC)[reply]

@Itcouldbepossible I suggest you follow up at WT:AWB as this would require maintainers of that client to do a rewrite. — xaosflux Talk 10:59, 19 June 2022 (UTC)[reply]
@Itcouldbepossible, changing the behaviour may mean the loss of the 'last accessed item' window which can be useful. Multiple sessions can be used and if 'in the zone' on a list then one session can work from the list top and the other the bottom. Swapping between sessions, sure it's extra work but not onerous. Neils51 (talk) 03:35, 22 June 2022 (UTC)[reply]
@Neils51 Can you please elaborate, like how can we run two sessions? Then we will have to click save on the sessions, then again, and again like this simultaneously. Won't that be troublesome? Itcouldbepossible Talk 08:06, 24 June 2022 (UTC)[reply]
Multiple sessions is a case of multiple startups/logins in the usual fashion on your chosen device. Works fine on Windows though I don't know with Linux, YMMV. I rotate via selecting the taskbar thumbnails and I think the most sessions I have rotated through is five. By the time you get back to the first it has definitely finished its writeback (it may be possible to rotate sessions via script?). The time taken to read and process a new item will be dependent on a number of factors, including size of pages, additional regex in your normal/advanced settings, function option selections, etc. I suppose it depends on the way you work and what you are endeavoring to achieve. For instance some editors will look at a list of 1500 items and want to process them in one hit whereas I may decide to take two weeks. As Kusma has mentioned an AWB editor must also be checking all edits and that can take time. A responsible AWB editor will sometimes come across rule exception conditions and have to decide as whether it's a one-off or perhaps there may need to be exception modifications made to a rule, or at least make a post to advise others and get their input. In an ideal world AWB would have an option for sync or async writeback operation. However, I'm reminded of a previous life when a piece of software was issued that met the original design requirements and then the change requests start coming in and a colleague comments that "apparently we need to rewrite the operating system". :-) It's possible that someone will take this on as a project one day, creating a separate thread, however today there are ways of being quite efficient with AWB and there are bots for the big lists! Neils51 (talk) 10:29, 24 June 2022 (UTC)[reply]
You can also run AWB in pre-parse mode, which will then only present you with articles that AWB could edit according to the rules you've setup. Headbomb {t · c · p · b} 12:22, 22 June 2022 (UTC)[reply]
@Headbomb You have possibly misunderstood me. I am talking about saving edits one after the other without actually waiting for AWB to save it. There should be a save queue. We can perform whatever actions we like, like saving or skipping. AWB will save them one by one like as in a queue. For example, we have processed what we will do in 50 pages, and a queue has been formed, and AWB has saved, say, 42 pages. Then it will likewise save the rest of the pages, which the user has already mentioned. If you use Huggle, you will understand better about the queuing. Won't this be more effective? Itcouldbepossible Talk 08:09, 24 June 2022 (UTC)[reply]
I think your suggested feature is too likely to be abused by people who won't review all of their edits. (Anyone who uses AWB without reviewing all of their edits should get a bot account or have their access removed). —Kusma (talk) 08:16, 24 June 2022 (UTC)[reply]
@Kusma There are many pros and cons of a given feature. For example, the mass rollback script, it can be dangerous and useful too. So like this everything has its good and bad side. And moreover I don't think untrusted users would have their AWB access request accepted. Users with good track of editing and those who are reliable are given AWB access. Still if someone misuses something, well, then admins can use this feature upon them. But it shouldn't stop any development from taking place. Itcouldbepossible Talk 08:33, 24 June 2022 (UTC)[reply]
How will your proposed change make sure you can only save edits after you have manually reviewed them? I have seen too many "trusted users" who believe that AWB can fix typos and then introduce one typo that changes the meaning of things (the typo fix "new york"->"New York" can produce things like "New York Mall" when something is about the "new York Mall", a new mall in York, making it sound like it is on a different continent) per a couple dozen small fixes that don't affect meaning (say, changing it´s to it's). People are not careful enough with AWB as is, and too often not willing to take responsibility for their edits, blaming them on the tool. —Kusma (talk) 08:48, 24 June 2022 (UTC)[reply]
@Kusma Actually it is not that. There are types of edits which always doesn't need to be reviewed. For example a regex that removes a parameter from a given infobox and only from that infobox and from nowhere else. Those type of edits doesn't need to be always reviewed since Regex wouldn't possibly remove something wrong. And people don't close there eyes and hit save, if in a hurry they make a wrong edit, they can always revert it. It has happened many times with me. I revert if I made a wrong edit. Typo fixing and fixing errors in new pages is what needs strict review. Things like I ones I mentioned needs only speed to save time and clear maintenance categories. You can also think of AWB bots in a way. They are running day and night. Who is reviewing them. But at the end of the day we see that it has done a lot of job and there are zero mistakes because of a fixed regex. Itcouldbepossible Talk 08:17, 25 June 2022 (UTC)[reply]
There are things that should be run fully automated, but why do they need a queueing mechanism? —Kusma (talk) 08:38, 25 June 2022 (UTC)[reply]
For what it's worth, as a botop this would be useful. Currently I'm checking around 200,000 pages and editing around half. At AWB's slow rate I expect this to take me around a month, or a week using multiple AWB sessions, even when running AWB for around 5 hours a day. Checking the edits obviously doesn't apply here, so this feature could easily be restricted to bots. ― Qwerfjkltalk 13:14, 24 June 2022 (UTC)[reply]
@Qwerfjkl But the problem with multiple sessions is that I would have to click on save on two or three windows, isn't it? Itcouldbepossible Talk 08:18, 25 June 2022 (UTC)[reply]
@Itcouldbepossible, yes, but I was talking about bots which can automatically save edits. ― Qwerfjkltalk 09:13, 25 June 2022 (UTC)[reply]

Please add more languages to Template:Comics infobox sec/lang[edit]

I am not sure if this is not obsolete, but it is still used by some comic infoboxes. I just noticed that Czech and Hungarian are not supported. Can they be added (needed for Funky Koval, FYI)? And ideally, this needs to be automatic, without people like me (and you) wasting our time on adding some languages... Piotr Konieczny aka Prokonsul Piotrus| reply here 15:32, 19 June 2022 (UTC)[reply]

I don't work with language templates but shouldn't it just use {{ISO 639 name link}} to work with all common languages? PrimeHunter (talk) 15:43, 19 June 2022 (UTC)[reply]
Yeah, ↑↑. In Template:Infobox comics meta series replace:
|data17 = {{Comics infobox sec/lang|{{{lang|}}}}}
with:
|data17 = {{#if:{{{lang|}}}|{{ISO 639 name link|{{{lang|}}}}}}}
caveat lector: not tested
Trappist the monk (talk) 16:16, 19 June 2022 (UTC)[reply]
Thanks. Can someone test and implement it? :) Piotr Konieczny aka Prokonsul Piotrus| reply here 10:38, 20 June 2022 (UTC)[reply]
Ping @PrimeHunter, @Trappist the monk. TIA. Piotr Konieczny aka Prokonsul Piotrus| reply here 08:55, 23 June 2022 (UTC)[reply]

TalkRead[edit]

recent version update mangled the display (vector-2022), and the top menu shows now "TalkRead". the "talk" part links to the talpage, and the "read" part does the same as the leftmost menu item ("Project" here, "Article" in mainspace, etc.).

arguably, the "read" part is superfluous, and in any case, as it is now, it's harmful, and mangles the display.

no doubt this will be fixed soon by the software, but in the meantime, it can be "patched" locally by editing medaiwiki:Skin-view-view, and saving it as empty page.

peace. קיפודנחש (aka kipod) (talk) 02:37, 20 June 2022 (UTC)[reply]

It looks like this is by design, one is an "indicator" that you are on the main page or the talk page, the other is an indicator that you are in 'read mode' or 'edit mode' while providing nav back to the other modes. I'm not seeing this "mangling" the display or otherwise making it ever have the words "TalkRead" actually attached to each other? Similar to Wikipedia:Village_pump_(technical)#Thursday_issues_in_Vector-2022? above, if you are seeing overlapping text would you please open a WP:BUG, include exact steps to reproduce, include screenshots, and then let us know the task number for follow up? I'm guessing you are possibly doing something like trying to use this skin with some sort of extreme resolution? — xaosflux Talk 10:24, 20 June 2022 (UTC)[reply]
Also, please check that this is not only happening for you when you have some custom userscript running. — xaosflux Talk 10:26, 20 June 2022 (UTC)[reply]
@Kipod, I don't see any issue in the English Wikipedia. I tried it with ?useskin=vector-2022, logged-in and logged-out, Firefox and Chrome. There may be a problem somewhere, but I suspect it's not universal. Amir E. Aharoni (talk) 12:00, 20 June 2022 (UTC)[reply]
guess it's something with my account. i should have tested it in "safe mode" before bothering the community. apologies.
peace - קיפודנחש (aka kipod) (talk) 16:01, 20 June 2022 (UTC)[reply]
UPDATE:
issue still exists, and is not user-account dependent, and also visible out-of account and in safemode.
_however_, it only visible when using chrome, and so far only detected on linux (specifically, "mint" distribution, with current chrome showing "Version 87.0.4280.66 (Official Build) (64-bit)".
i guess "issue with specific version of chrome, visible on linux only" is not worth dealing with. FF on same OS does not show the issue.
MORE PRECISE DESCRIPTION:
the issue has nothing to do with "read", but rather with the 2nd half of the top men, which is split in two: left part has "Project page" (or "Article" or whatnot, depending on namespace) and "Talk", and right part has "Read", "Edit source" and so forth.
when the issue materializes, the right half justifies leftward, such that "Read" is concatenated to Talk in the left part (hence "TalkRead").
again, this was only viewed with chrome browser, and only on linux. i tested chrome on chromebook and windows, and both display correctly, as does FF on linux.
peace. קיפודנחש (aka kipod) (talk) 18:14, 20 June 2022 (UTC)[reply]
@קיפודנחש the Chrome version you reported above is from Nov 2020, the current stable release is 102.0.5005.125 - can you verify if your browser-specific problem resolves if using the current version of Chrome? — xaosflux Talk 18:49, 20 June 2022 (UTC)[reply]
in the meantime, i dug a little more, and found that it's mw bug.
other browsers (and apparently, newer version of chrome) are more lenient, but it will be nice if mw can fix it anyway.
the issue has to do with "justify-content" attribute of the 2nd half of the menu (element id is #right-navigation).
mw set it up as "end" (i.e., justify-content: end;). this is illegal, even if most browsers respect it anyway: it's a "flex" container, and w3 says you should use "flex-end", not "end". see https://www.w3.org/TR/css-flexbox-1/#justify-content-property. when i manually changed the value on my browser to "flex-end", the display straightened up and showed correctly.
admittedly, this is a small bug, maybe not worth fixin', especially since most browsers are nice enough to interpret "end" as "flex-end". i happen to use linux mint, and apparently they are using way behind upstream top version of chrome. i can live with it, but it will be nice to fix the bug and use correct value for this attribute.
needless to say, the "solution" i suggested in 1st post is complete junk.
peace. קיפודנחש (aka kipod) (talk) 19:03, 20 June 2022 (UTC)[reply]
@קיפודנחש thanks for the udpate, please see WP:BUG for how to report the bug on phabricator where it could be fixed for all mediawiki users, placeing a local language-specific message hack isn't the right way to solve this. Please do let us know the task id so we can note it here for anyone that comes across this. — xaosflux Talk 19:11, 20 June 2022 (UTC)[reply]
thanks. i'll pass on the suggestion to create a task on phab:. i added the "update" here for completeness...
peace. קיפודנחש (aka kipod) (talk) 19:19, 20 June 2022 (UTC)[reply]
I think the W3 spec is outdated (at least compared to what browsers implement). The CSSWG's CSS Box Alignment Model Level 3 draft knows about end, though MDN's compatibility table does say it's only been supported in Chrome since version 93. So I'd say this isn't a bug per se, though it may still warrant changing, since both IE and Safari notably don't appear to support the feature. Rummskartoffel 19:29, 20 June 2022 (UTC)[reply]
Don'r rely on anything that isn't a full W3C Recommendation. CSS Flexible Box Layout Module Level 1 is a W3C Candidate Recommendation, and has been since March 2016 - it's been revised four times since then, so might not yet be stable enough to progress to a Proposed Recommendation. Indeed, back in 2014 it was busted from Candidate Recommendation back down to Last Call Working Draft, so this may well happen again. The fact that some browser vendors have chosen to implement these new features demonstrates that they are providing users with the ability to conduct tests. So what you could do is provide Chrome's authors with feedback on your experiences with this property. --Redrose64 🌹 (talk) 10:38, 21 June 2022 (UTC)[reply]
Well, yeah using a newer browser resolved the issue I noted in the above section. Noting that (even new version) Edge on Android probably doesn't respect the justify-content: end; thing. Chrome does though. CX Zoom[he/him] (let's talk • {CX}) 19:41, 20 June 2022 (UTC)[reply]

How to print a specific part source code of an article?[edit]

Hi, is there any template, tool, query or anything else to print a specific part of an article source wikitext given the article title and regex pattern? For example, I want to get the entire coord template from Ab Bar article. Thank you! ⇒ AramTalk 14:30, 20 June 2022 (UTC)[reply]

If what you want is the actual coordinates or some other values within the template call, you may be able to use {{Template parameter value}}. Certes (talk) 15:13, 20 June 2022 (UTC)[reply]
@Certes: Thank you for your reply! That’s a great template and solves a lot of my problems, but in my question I meant the wikitext, not the actual value. For example, I want to get this: {{coord|36|55|21|N|48|58|28|E|region:IR|display=inline,title}} Thanks! ⇒ AramTalk 20:48, 20 June 2022 (UTC)[reply]
The nearest I can get is something like {{#invoke:string|match|{{:Ab Bar}}|%{%{coord.%}%}|}}, which does not work because {{coord}} has already been expanded before #invoke:string sees the wikitext. A modified copy of Module:Template parameter value should be able to do the job, or there may be some other way to get the actual wikitext without its templates getting expanded. (That shouldn't be hard to write, and I can't believe no one has done it, it's just a question of guessing what they might have called it.) Certes (talk) 21:50, 20 June 2022 (UTC)[reply]
@Certes: Thank you very much for your answers! I hope someone makes such a template because it is really important to have one. ⇒ AramTalk 11:33, 21 June 2022 (UTC)[reply]
@Aram: just to make sure that there isn't an XY problem going on – what are you trying to accomplish? It might be that you would be better off getting the coordinates from Wikidata. Article Ab Bar is Q861916 on Wikidata, and coordinates are stored in Property:P625. Using Template:Wikidata: {{wikidata|property|Q861916|P625}} → 36°55'21"N, 48°58'28"E. —⁠andrybak (talk) 18:34, 22 June 2022 (UTC)[reply]
@Aram, @Certes, you could try
{{#invoke:string|match|{{#invoke:Page|getContent|Ab Bar|as=raw}}|%{%{coord.%}%}|}}
using {{#invoke:Page|getContent}} ― Qwerfjkltalk 20:55, 22 June 2022 (UTC)[reply]
Thanks: Page is exactly the module I was looking for. The above solution preserves a typo from my failed attempt. I left out a hyphen (non-greedy quantifier); it should read {{#invoke:string|match|{{#invoke:Page|getContent|Ab Bar|as=raw}}|%{%{coord.-%}%}|}}. Certes (talk) 21:36, 22 June 2022 (UTC)[reply]
@Andrybak: Actually, we are working on creating all Iranian cities (about 1,000 articles on ckbwiki) using a bot. Our biggest problem was getting the coordinates. The coordinates are on Wikidata, but some pages (on Wikidata) have more than one value and we should use regex to shape them as a wikitext. However, I worked hard on them after your reply, but didn't get very accurate results. I was very pleased with your answer and I am sure I can use it elsewhere. Thank you very much for your reply!
@Qwerfjkl: and @Certes: It's incredible! Thanks for improving the code above to give us exactly what we want. I was working on the code above a little while ago, but I put a plus sign (+) after the dot (.) and brought it up to the stub template. :( After User:Certes replied, I was surprised that you made it. :) That would be great if you can make it into a new template for those who want to get Wikitext in the future. I still can't believe it! Thank you all so much! ⇒ AramTalk 22:26, 22 June 2022 (UTC)[reply]

Overwriting a filename used on Commons locally[edit]

Is there a way to re-use a name already in use on Commons? Specifically, looking at commons:File:Cadillac (logo).svg vs. File:Cadillac (ACTUAL logo).svg. I wasn't sure if I was missing an option, since the upload wizard seemed to indicate it was acceptable it just had to be confirmed, but it wouldn't actually let me upload to that name locally. —Locke Coletc 02:08, 21 June 2022 (UTC)[reply]

@Locke Cole yes, it requires the (reupload-shared) permission - that only admins have. This is normally a bad idea and should really only be used for some special cases where we have extremely high-used images locally. — xaosflux Talk 15:09, 21 June 2022 (UTC)[reply]
It seems odd to allow a file, unused anywhere I might add, on Commons to hold a name on this project for a file that is clearly fair-use and will likely never qualify to be uploaded to Commons. Regardless, the upload wizard text should be changed to reflect that it can't actually be overridden unless the uploader is an administrator. The current text simply leaves the impression that you have to confirm your action, not that it can't be done. —Locke Coletc 15:42, 21 June 2022 (UTC)[reply]
@Locke Cole I think the better solution would be to move the file on Commons, since it's unused and isn't a logo. --Ahecht (TALK
PAGE
) 15:53, 21 June 2022 (UTC)[reply]
I'm still trying to suss out why a local project is being forced to abide by the name of a repository? I get having a warning to discourage people from overwriting files there, but there's no reason to restrict this for users who are experienced and show no history of vandalism. I seem to recall overwriting files stored on Commons locally in the past, so clearly this was a change that was made, I'm just curious about the reasoning, the policy/guideline, and when/where the discussion was. —Locke Coletc 16:57, 21 June 2022 (UTC)[reply]
Name shadowing is the worst, period, and multiple people here have had to deal with the mess it leaves in the general case. As Ahecht has said, the name on Commons sucks, so the image there should be moved. Izno (talk) 17:46, 21 June 2022 (UTC)[reply]
It's been at least 10 years - I'm not feeling like an archeologist right now to go through config files - but it would be out there in the codebase somewhere; "reupload-shared" seems to have been created in 2005 - not sure when enforcement started here. — xaosflux Talk 17:56, 21 June 2022 (UTC)[reply]
c.f. Currently you cannot upload a new local image if there's a conflicting image on Commons.... from Wikipedia:Village_pump_(technical)/Archive_H#error_on_image_load (2005). — xaosflux Talk 18:04, 21 June 2022 (UTC)[reply]
Thank you for the historical perspective. —Locke Coletc 15:15, 22 June 2022 (UTC)[reply]
@Locke Cole The file on Commons has now been moved out of the way. You should be good to go. --Ahecht (TALK
PAGE
) 03:10, 22 June 2022 (UTC)[reply]
@Ahecht: Sadly, no. The page could not be moved, for the following reason: The filename chosen is already in use on a shared repository. Please choose another name. I suspect because while the file was moved, a redirect exists. —Locke Coletc 15:12, 22 June 2022 (UTC)[reply]
Nominated for speedy deletion. Rummskartoffel 21:44, 23 June 2022 (UTC)[reply]

Confusing automated filter warning[edit]

I've just made an edit to Psychology of collecting (diff: [1]) and after clicking publish I got this popup. File:Confusing_automated_filter_warning.PNG

I had this happen one time before where it was more obvious and I was able to remove the offending source. In this case, I don't know if the filter warning was referring to citations present that I had removed which were marked as self published sources, and among the sources I added and read they all seemed reliable to me for the scope of the article. (I could be wrong about that though.) My point is I am getting a warning, which I am not even sure is relevant to my edit, which I can't fully read due to a non-resizable window, and does not clearly tell me which citation/s I added are from a predatory journal. Appreciate any help with this. Darcyisverycute (talk) 11:50, 21 June 2022 (UTC)[reply]

@Darcyisverycute You can view the full message, with the list of predatory journals, at MediaWiki:Abusefilter-warning-predatory. The display, however, does seem like a bug, and I would recommend reporting that on Phabricator: https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=VisualEditor --Ahecht (TALK
PAGE
) 14:06, 21 June 2022 (UTC)[reply]
This was phab:T184379. I guess they've made the dialog as big as they're going to. It should be scrollable, but also I believe it's on us to use TemplateStyles or something else to conditionally show smaller messages based on the viewport size. This isn't a bad idea anyway as mobile users can face the same problem. MusikAnimal talk 21:56, 21 June 2022 (UTC)[reply]
I am pretty sure the primary problem here is that the caption is set to nowrap. The secondary problem would indeed be related to the message box having certain expectations in which it is displayed, which VisualEditor has more or less so far failed to accommodate since edit filter messages were first supported, and which certainly cannot be fixed before container media queries are well supported (and even in the current proposal, mw-parser-output would also need to be set in CSS to be a valid container for queries, which I've been thinking about filing a task for a bit now and just haven't done so because they aren't implemented yet). Izno (talk) 02:30, 22 June 2022 (UTC)[reply]
Why is there an entire table here though.. Just link to a a page with the details...
Another easy improvement we can make. If .oo-ui-popupWidget-popup .*mbox then kill margins, decorative images etc. Is it good, is it how it should be done ? no, but it fixes an immediate problem. —TheDJ (talkcontribs) 14:26, 22 June 2022 (UTC)[reply]
Yes, that would fix it, but also split the styles from their soon-TemplateStyled home. (I literally just need to fix Module:Listen and then deploy a new version of Module:Side box before we can do that. We're almost there!)
I would have no personal issue removing the table. Good luck on that mission! Izno (talk) 16:08, 22 June 2022 (UTC)[reply]
This error message would also look broken on mobile, where we can't make the screen wider. Matma Rex talk 15:11, 22 June 2022 (UTC)[reply]
Yes, but on mobile we're at a resolution where you could use media queries to affect the presentation. (That we don't yet is simple technical debt that at least TheDJ has played around with resolving but which hasn't been merged into the relevant styles.) In other words, VE continues to have no reason why this flyout is as small as it is. Izno (talk) 16:06, 22 June 2022 (UTC)[reply]

Proposal to change citation templates which hurt articles' Google ranking[edit]

Many archived links used in citation templates have a dead link which says "the original". This hurts ranking in Google, because while the reader can pass over it, the crawler picks it up and Google's algorithm processes it as if the article is full of dead links. This can make articles appear lower on Google search results than they would otherwise. How could this be fixed?
Which of these ideas do you like best, or do you have other ideas?

  • dead links could have a non-hyperlinked url text following "the original"
  • or "the original" could have a tooltip text with the url instead of a hyperlink
  • the link status parameter could be given three possibilities: "dead", "permanent dead", and "live", with "permanent dead" showing a non-hyperlinked url instead of a dead link to "the original".
  • a "permanent dead" link parameter could show a non-hyperlinked url as a tooltip text instead of a dead link to "the original".

--Epiphyllumlover (talk) 15:06, 21 June 2022 (UTC)[reply]

@Epiphyllumlover can you provide some actual examples of these links from articles? — xaosflux Talk 15:11, 21 June 2022 (UTC)[reply]
Little_Rock_Central_High_School#cite_note-nhlsum-4 is one. A benefit of linking to "the original" is that link might become live. Yet "the original" here shows up as a dead link to a crawler.--Epiphyllumlover (talk) 15:17, 21 June 2022 (UTC)[reply]
See also the subsection in {{cite web}} doc (with examples): cite web § Using "archive-url" and "archive-date" (and optionally "url-status") for webpages that have been archived. Sorry for the somewhat facile answer and redirect. 50.75.226.250 (talk) 15:18, 21 June 2022 (UTC)[reply]
I believe the first option (non-linked URL) is best. Tooltips raise accessibility and compatibility concerns. Adding a "more dead than dead" parameter may be convoluted, and overly complex for developers, users and readers. 50.75.226.250 (talk) 15:24, 21 June 2022 (UTC)[reply]
To clarify, you recommend "unfit" for dead links unlikely to become live again?--Epiphyllumlover (talk) 15:26, 21 June 2022 (UTC)[reply]
Oh, I understand now.--Epiphyllumlover (talk) 15:27, 21 June 2022 (UTC)[reply]
Assuming for the sake of the argument that dead links do hurt PageRank (I have no idea if that is the case), I would prefer that we optimize for page layout rather than for search engine ranking. That being said, if there is a way to tell a "permadead" link from a "tempdead" one, why not unlink the former. TigraanClick here for my talk page ("private" contact) 15:29, 21 June 2022 (UTC)[reply]
I think predictions of a link becoming live in the future are like looking into a crystal ball, highly stochastic. 50.75.226.250 (talk) 15:36, 21 June 2022 (UTC)[reply]
External links also have nofollow. I imagine that damages their page rank significantly more than the text in the link itself. Izno (talk) 16:02, 21 June 2022 (UTC)[reply]
Either way, I see no reason to help Google here. Dead links in "the original" are either temporarily or permanently dead, so their accessibility by any old user is also probably worse for their page rank than anything we can do to the text of the link. There is no reason to help Google find them in any sense. Izno (talk) 16:03, 21 June 2022 (UTC)[reply]
The best venue for discussing changes to the Citation Style 1 templates (e.g. cite web, cite book) is Help Talk:CS1. – Jonesey95 (talk) 17:08, 21 June 2022 (UTC)[reply]
Tigraan, yes, unlinking would be fine with me, that advice was also given on stackoverflow. There is uncertain information online about how dead links affect search rankings. It is possible that some (low-quality) links don't really matter one way or the other whether they are alive or dead. If you are wondering about this, you can search for advice like, "do dead links hurt SEO". Generally it is recommended to fix them for one reason or another. I experimented with one article that was sagging in search rankings by removing the dead link url and putting the archival url into the url parameter and adding (Archived...) just outside of the citation template. It lasted awhile before it got changed back, but while it lasted it seemed to help. Search engines don't just give out their "secret sauce" algorithm; people have to guess it and test for it. More testing could be done about this on wikipedia too.
50.75..., yes, some dead links are anyone's guess about living again. Yet there are some categories of dead links which are unlikely to ever live again, such as links to long-defunct websites and multiple links to government sites or pdfs which all follow the exact same url format, and which die all at once.
Izno, Google does not strictly obey nofollow code on links anymore. This official policy change from March 2020 had previously been suspected by some to be their practice. I wonder if the nofollow code was supposed to protect Wikipedia from the bad SEO effects of dead outbound links. We don't need to avoid the dead links for Google's benefit. Yet some articles about popular topics may not be on the first page of search results. They get buried instead; I am concerned about that. I agree that there is some benefit to any old user in not hyperlinking dead links known and expected to stay dead.
Jonesey95, thank you for the talk page. Especially with having it show non-hyperlinked text instead of a tooltip, the coding changes at hand deal with only the template. I will link to this discussion there, and it might end up getting continued there too. Changing the template will also affect some bots.--Epiphyllumlover (talk) 17:46, 21 June 2022 (UTC)[reply]
Re "I wonder if the nofollow code was supposed to protect Wikipedia from the bad SEO effects of dead outbound links" - nofollow was turned on for external links in mainspace in Jan 2007 explicitly to deter spam by removing the SEO incentive (announcement). I don't think the effects on our own search engine rankings were something anyone considered at that point. Andrew Gray (talk) 06:32, 22 June 2022 (UTC)[reply]
Unlinking is a bad idea. It makes things much harder to verify (e.g. is the link truly dead or not?). What Google does is irrelevant. Headbomb {t · c · p · b} 12:20, 22 June 2022 (UTC)[reply]
To verify, one would copy and paste the url text from the reference. It is some additional effort.--Epiphyllumlover (talk) 18:19, 22 June 2022 (UTC)[reply]
What Headbomb says has traditionally been the accepted rationale. In light of this new information, it carries much more weight to remove the hyperlinks. It's a tradeoff. The benefits of increased page views can't be overstated. -- GreenC 19:35, 22 June 2022 (UTC)[reply]
@Epiphyllumlover, Also, verifying if the dead links is an editor task, not a reader task. It doesn't seem to0 much to ask of the small subset of editors that actually verify these links to copy & paste a URl (though maybe it's harder than one would think). ― Qwerfjkltalk 13:09, 23 June 2022 (UTC)[reply]
Maybe a bot could be written to verify that urls labeled as permanent dead links are still dead. One problem would be permanent dead links which were recreated by a domain parker or content farm; I have seen that happen. So maybe humans would be required to do the work.--Epiphyllumlover (talk) 16:11, 23 June 2022 (UTC)[reply]
This problem is probably infrequent; a workable solution would be a bot which verifies the links are still dead, and makes a list for human editors of links which aren't. Animal lover |666| 08:20, 24 June 2022 (UTC)[reply]
User:InternetArchiveBot had a bad spate of thinking websites were down when they weren't, so it's probably more common than you would expect.
It might also be a good idea to restrict IABot to adding archive links within ref tags. WP:ELDEAD only rarely wants archive links in the ==External links== section. WhatamIdoing (talk) 17:39, 24 June 2022 (UTC)[reply]
Do nothing Since when does Wikipedia care about an article subject's SEO? This is an issue between the subject and Google, it's not our problem. We're an encyclopedia, not a marketing vehicle. Roger (Dodger67) (talk) 12:31, 22 June 2022 (UTC)[reply]
There are two graphs, (recent and older) at stats.wikimedia.org. The graphs show rather consistent growth prior to October 2013, a period of flat viewership, and then there is a peak in April 2020. Since then it has overall gone down. April 2020 is just after the March 2020 announcement by Google that their policy changed. It is suggestive that the policy change hurt viewership. If your "Do nothing" option is what happens, how much lower would the views need to go for you to reconsider? (10% loss? 20%? etc.)--Epiphyllumlover (talk) 18:12, 22 June 2022 (UTC)[reply]
I read that page view graph as "flat since 2016, with a COVID spike in 2020". I see zero evidence for your suggestion. —Kusma (talk) 18:24, 22 June 2022 (UTC)[reply]
Yes, there is a Covid spike, and also seasonal factors. But look at the graphs again, trying to account for that. Google Knowledge graphs corresponds with the major hit on the older graph, although it didn't set in all at once. There is also a smaller hit to viewership on the recent graph. Changing it to monthly can help with comparing specific months with the same months in prior years.--Epiphyllumlover (talk) 18:29, 22 June 2022 (UTC)[reply]
We should pay zero attention to the Google rankings of our articles, and we should not try to optimise them every time Google changes their algorithm. Improve the article quality, not search rankings. —Kusma (talk) 18:29, 22 June 2022 (UTC)[reply]
Would you take the same position if viewership fell more? At what degree of loss would you reconsider?--Epiphyllumlover (talk) 18:32, 22 June 2022 (UTC)[reply]
If readership drops by a quarter, I will start to be interested why. Do they not click through to our page because Google's snippet is good enough? Do they read our articles at Wikiwand instead because our layout sucks? The only reason to prefer to have readers here instead of at a mirror is the small chance of converting them into editors. Where do you think the potential readers we might be losing because of the dead link issue are going? —Kusma (talk) 18:53, 22 June 2022 (UTC)[reply]
I would happily give away half of our viewers in exchange for a doubling of active editors. —Kusma (talk) 19:14, 22 June 2022 (UTC)[reply]
Active readers is the pool active editors derive from. Reduce one the other will go down. Search engines are the main driver of active readers. -- GreenC 19:25, 22 June 2022 (UTC)[reply]
Still, if we can choose between expanding effort on improving the conversion rate reader->editor by 10% or increase total readership by 5% I would choose the conversion rate. —Kusma (talk) 20:38, 22 June 2022 (UTC)[reply]
IMO anecdotal opinion a prime reason Wikipedia is so successful is Google. Without that, readership would probably 50% or less, the site would have less social impact, less importance, fewer people who cared, less money etc... Good or bad, how it is. Wikipedia is not unique in that position. Big Tech sucks but also real. -- GreenC 19:10, 22 June 2022 (UTC)[reply]
When we had fewer readers, we didn't have the terrible amount of responsibility to get it right that we have now. —Kusma (talk) 19:16, 22 June 2022 (UTC)[reply]
The SEO thing is a death by a thousand cuts. There are other things on Wikipedia which could be changed to improve SEO, and might have a larger impact, but this seems to be one of the easiest possible changes.
The Knowledge Graph is part of the issue, both the snippet and the sample questions and answers. The questions and answers may appear above the article. And the attractiveness of the sample questions and answers is compounded by having the wikipedia article's placement being lower down, maybe under even irrelevant placements. The usual winners are businesses and organizations who practice SEO. For example, if I search for "Door Peninsula" in Google, the top result is the "Door Peninsula Winery". Number two is the wikipedia article. So the Door Peninsula Winery is the winner in that case. But so is Google, because if they can keep viewers from seeing the wikipedia article so easily, they'll spend more time on Google. And the more time they spend on Google, the more click-throughs Google gets on their ads. In the early days of Knowledge Graph it seemed like they were more likely to be derived from Wikipedia, but now most of them aren't. The content is aggregated from all over.
I wonder what the viewership is on wikiwand, I couldn't find it. The figures, if they are high enough, have the possibility of changing my perspective.
A redeeming factor to this is that none of the larger wiki encyclopedia forks are exploiting this. If one of them decided to get serious about SEO, that could change, but I don't see that happening. Recently I saw one of the smaller wiki content sources (a niche topic site rather than a clone site) beat Wikipedia for awhile on a specific search, but now Wikipedia is ahead again.--Epiphyllumlover (talk) 19:36, 22 June 2022 (UTC)[reply]
For me (in the UK), the Wikipedia article is the top result, followed by Britannica and Expedia. —Kusma (talk) 20:36, 22 June 2022 (UTC)[reply]
When I search for "door peninsula" on Google, I get the WP article, FWIW. Wait a minute, Google displays ads? I haven't seen an ad on Google for 15+ years. – Jonesey95 (talk) 20:57, 22 June 2022 (UTC)[reply]
If you search in quotes, the winery is first. I just searched without quotes, and the article is first. Strange, isn't it?--Epiphyllumlover (talk) 23:14, 22 June 2022 (UTC)[reply]
I get the Wikipedia article at the top in both searches, but I can replicate the behaviour you see by using a VPN that geolocates to the United States. —Kusma (talk) 08:44, 23 June 2022 (UTC)[reply]
Some time back I submitted a complaint to Google about listing the winery first. That might be why one search is different than the other.--Epiphyllumlover (talk) 16:06, 23 June 2022 (UTC)[reply]
The winery doesn't show up till half way down the page for me. Search results are personalised, so taking any one results as being meaningful is a mistake. - LCU ActivelyDisinterested transmissions °co-ords° 19:52, 23 June 2022 (UTC)[reply]

Image request for UK people or Ireland[edit]

Is this possible to request images? Is anyone going to Restricted Forest Festival, Back to Festival, Falkirk Club, Edniburgh City 7S/Dundee Club, Glasgow Club, Drogheda Club, Colour Clash Festival/Club Cardiff, Clubland in the Beach, Doncaster Club or Guildfor Club in UK or Festival Punchestown in Ireland and could take photo of event and Basshunter? List of locations: Facebook, Instagram or Twitter. Eurohunter (talk) 16:17, 21 June 2022 (UTC)[reply]

@Eurohunter this seems quite off topic for VPT. See Wikipedia:Requested pictures. — xaosflux Talk 16:35, 21 June 2022 (UTC)[reply]
@Xaosflux: Good idea but there could be option to reach and more or less ask directly Wkipedians who live exactly in these places or if they are just going there for ocassion than listing them in more general category. Eurohunter (talk) 17:14, 21 June 2022 (UTC)[reply]
@Eurohunter You could try to organize a photo-a-thon and ask for it to be advertised via Wikipedia:Geonotice. — xaosflux Talk 17:16, 21 June 2022 (UTC)[reply]
There is a large and active requesting list on commons (c:Commons:File_requests). You can also post it to WP:REWARD, then along with a wikiproject, you can ask for the WP:SIGNPOST to carry it.--Epiphyllumlover (talk) 18:32, 21 June 2022 (UTC)[reply]

Wikilinks from italic titles[edit]

When editing the article Baltic Sea cruiseferries, I have had for numerous times to type [[MS So-and-so|MS ''So-and-so'']]. Would it be possible for the wiki software to simply ignore the italic signs and interpret [[MS ''So-and-so'']] as a direct wikilink to [[MS So-and-so]]? JIP | Talk 01:56, 22 June 2022 (UTC)[reply]

This would break quite a few pages. Consider using an appropriate ship prefix template (the primary one is {{ship}} I believe). Izno (talk) 02:33, 22 June 2022 (UTC)[reply]
{{MS|Finnstar}}MS Finnstar
Trappist the monk (talk) 02:54, 22 June 2022 (UTC)[reply]

Minor one-time glitch, probably: exception encountered when moving page[edit]

Just wanted to put this somewhere before I lose it. Tried moving Lisa Ellis (fighter) to Lisa Ellis (martial artist) on Safari on a mobile device on mobile Wikipedia and received the following:

[b92c7ff8-12fe-47d0-9498-dd4c2e77e0cc] 2022-06-22 08:14:36: Fatal exception of type "MWException"

The move succeeded, so maybe I double-tapped by accident? Rotideypoc41352 (talk · contribs) 08:25, 22 June 2022 (UTC)[reply]

You've hit this known issue: phab:T235589. Likely indeed it is because of a double tap. —TheDJ (talkcontribs) 14:19, 22 June 2022 (UTC)[reply]

Main Page Popup[edit]

Hi, I also asked this question on the main page talk page. Upon using an internal wikilink to the main page (like this), the page preview shows an error like the one in the screenshot.

Wikipedia Main Page preview

Since the main page is mostly templates and the like, this is expected, but isn't there a way to change the text to something more friendly, like "The Wikipedia Main Page"? Thanks. Urban Versis 32KB(talk | contribs) 02:45, 23 June 2022 (UTC)[reply]

Lag in edit window with Microsoft Edge Toucan browser extension[edit]

I am having trouble editing pages over 25,000 bytes in Edge. The larger the page, the more the cursor and typed words lag. Taylor Swift crashed my browser tab. I have experienced a similar issue that was resolved. See Wikipedia:Village pump (technical)/Archive 193#Performance issue with syntax highlighting. Safemode does not fix the problem, however, logging out does. I am using Windows 11 v. 21H2, Microsoft Edge v. 102.0.1245.44. I have not reproduced this in Chrome. Schierbecker (talk) 07:09, 23 June 2022 (UTC)[reply]

I figured put that the problem is resolved when I disable the Toucan browser extension. Schierbecker (talk) 07:38, 23 June 2022 (UTC)[reply]

Global projects being too wide since yesterday[edit]

Hi all, as many of you know I almost always use mobile device in desktop mode. Suddenly, since yesterday the global projects (commons, meta, wikidata) became way too much wide, and thus, the text became too small. This issue has never happened in the past. Meanwhile, the Wikipedias (en, bn, pi, etc.) are fine as of yet. Screenshots of main pages of commons, meta and enWikipedia are attached. Thanks! CX Zoom[he/him] (let's talk • {CX}) 07:34, 23 June 2022 (UTC)[reply]

Added a screenshot of a Wikidata content page too, as that too looks awful enough to be included here. CX Zoom[he/him] (let's talk • {CX}) 08:31, 23 June 2022 (UTC)[reply]
This is a WP:ITSTHURSDAY thing, and will probably hit us too. The Devs™ have decided that people can't read long lines of text and they have seen fit to artificially constrain the width for us. Now, speaking personally, I bought a wide monitor because I want long lines of text - those big white stripes up the left and right are a complete waste of space, and have all the appearance of being set aside ready for the day that Wikipedia carries advertising. On those occasions that I want shorter lines, I unmaximise the window and drag the left or right window borders until I get the width that I want. --Redrose64 🌹 (talk) 07:51, 23 June 2022 (UTC)[reply]
I wish they'd listen to that advice. I do see advantages to short lines. By not making the browser window full screen, I can make the lines any (shorter) length I like, and recycle the freed space for another window containing a source document, another wiki page or my shopping list. A compromise might be to make the text a main element (it's still the most important item, isn't it?) and the right column an inner element within it which can be suppressed with JavaScript or ad blockers, but I don't see that happening. Certes (talk) 08:18, 23 June 2022 (UTC)[reply]
> The Devs™ have decided that people can't read long lines of text and they have seen fit to artificially constrain the width for us. "
Not sure what this has to do with a mobile device or the issue raised here? Jon (WMF) (talk) 14:49, 23 June 2022 (UTC)[reply]
The train was stopped last night, which in plain English means that this change (as-is) will never come to the English wikipedia. It was solely stopped because of the issue in this task (source: phab:T308070). An less aggressive change along the same lines will still be done, however. phab:T306910 caused this change.--Snævar (talk) 11:52, 23 June 2022 (UTC)[reply]
Pinging Jon (WMF) as requested in the Tech News article. – Jonesey95 (talk) 14:42, 23 June 2022 (UTC)[reply]
This was fixed in the last hour. You may need to purge your page. Please let me know if you are still experiencing this issue ASAP. Jon (WMF) (talk) 14:46, 23 June 2022 (UTC)[reply]
@Jon (WMF): Was away. Looks like we're back to normal. Thanks for fixing. CX Zoom[he/him] (let's talk • {CX}) 18:39, 23 June 2022 (UTC)[reply]
Thanks for letting us know! Phew! :D Jdlrobson (talk) 19:10, 23 June 2022 (UTC)[reply]

Broken reflist at List of musical works in unusual time signatures[edit]

Hi, this good faith edit appears to have broken the reflist for the page. But, for the life of me, I can't figure out how. I've tried tweaking parts of the references and even deleting the original citation and re-inserting it, but no dice. I am, however, getting the following warning:

Script warning: One or more {{cite web}} templates have maintenance messages; messages may be hidden (help).
Script warning: One or more {{cite book}} templates have maintenance messages; messages may be hidden (help).
Script warning: One or more {{cite news}} templates have maintenance messages; messages may be hidden (help).

I have no idea what this means. Any of you more technical folks know what's going wrong here? — Czello 17:25, 23 June 2022 (UTC)[reply]

WP:Template limits. Essentially, too many templates with too much stuff in them. Let me try step 1 and see how far it gets us. Izno (talk) 17:40, 23 June 2022 (UTC)[reply]
Ok, so step 1 worked. Anyway, to further fix the uses of templates that come after the reference list you will need to reduce the uses of {{music}}. Whether that's some sort of page split or simply raw removal is up to you. Izno (talk) 17:43, 23 June 2022 (UTC)[reply]
The third thing that might help would be to make the template into a module. --Izno (talk) 17:47, 23 June 2022 (UTC)[reply]
{{Time signature}} could probably be modified to use Module:Su directly without making the code a lot worse to parse. – Jonesey95 (talk) 17:50, 23 June 2022 (UTC)[reply]
{Time signature} is already using Module:Su via Template:Su; are you suggesting removing that one layer will be a substatial improvement? Wouldn't replacing {Music} calls with (Time Signature} calls be better? (I don't know if template size is an issue or just number of templates.) - R. S. Shaw (talk) 00:34, 24 June 2022 (UTC)[reply]
Before applying any fixes to any templates or modules, perhaps the correct thing to do for this article is to reduce the unnecessary redundancy. For example, §1
8
has these (the first three; other entries similar; references removed):
Since that section is the 1
8
section, it seems pointless to me to repeat the 1
8
time signature in every entry of the section. Additionally, since this is §1
8
and Mädchentotenlieder is also mentioned in §1
16
, there is no need to mention the 1
16
time signature in Mädchentotenlieder's entry in §1
8
. Removing the redundant {{music}} templates would, it seems to me, go a long way towards fixing that list article.
Trappist the monk (talk) 18:22, 23 June 2022 (UTC)[reply]
Yes, that was my inclination as well. Izno (talk) 20:02, 23 June 2022 (UTC)[reply]

Vector 2022: project update and invitation to the next meeting[edit]

Hey, if you don't watch the miscellaneous section you may ignore a message you perhaps would prefer not to ignore, so this is like a redirect within the VP to increase the visibility.

In a nutshell:

  1. We would love to see Vector 2022 become the default for readers and editors across all wikis. In the coming weeks, we will begin conversations on English Wikipedia.
  2. It will always be possible to revert to the previous version on an individual basis. Monobook or Timeless users will not notice any changes.
  3. Join an online meeting with our team. It will take place on 28 June 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location. The following events will take place on 12 July and 26 July.

Thanks and see you! SGrabarczuk (WMF) (talk) 18:51, 23 June 2022 (UTC)[reply]

Pop-up for disambig pages[edit]

Hi all, is there a way to disable the big pop-up that appears on the right when you preview an edit with a new link to to a dab page? I already have "Display links to disambiguation pages in orange" in Preferences/Gadgets selected, which is quite sufficient for me. Cheers, MinorProphet (talk) 21:42, 23 June 2022 (UTC)[reply]

@MinorProphet: in Special:MyPage/common.css (or in your specific skin file) put this line to hide it:
.mw-disambiguator-notification{display: none;}
xaosflux Talk 23:26, 23 June 2022 (UTC)[reply]
@Xaosflux: Great, that seems to work. Thanks very much. On the same subject, is it possible to disable the pop-up when you hover over an orange link? (Except for your name, of course) Cheers, MinorProphet (talk) 00:23, 24 June 2022 (UTC)[reply]
@MinorProphet I'm not sure which one that is? Are you getting the notification area popup there too, or is this the normal popup you get for all links (should appears near where you mouse is). — xaosflux Talk 09:18, 24 June 2022 (UTC)[reply]
@Xaosflux: Sorry, I've realised it's the usual popup, saying "This title relates to more than one page", with a blue link to "View similar pages", eg Buc and Buc, Yvelines. I've changed my browser preferences to "Always open links in a new tab", which I think solves the problem for me. Thanks again for your kind assistance. MinorProphet (talk) 09:56, 24 June 2022 (UTC)[reply]

Unable to manage font size[edit]

I acquired an iPad Pro a few weeks ago, which I've been using to read & edit Wikipedia at home -- amongst other things. Today when I opened a new page on Wikipedia, I was surprised to find the font about 50% larger than it had been last night. According to the documentation (which Apple likes to hide because "if you need to read the manual the user interface has failed"), I can adjust the font size by pressing the Cmd & + (or the cmd & -) keys at the same time. This didn't work. Nor did going to another Wikimedia project: the font was 50% larger there with no way to reduce its size. (I might have eye problems, but being forced to use a larger font doesn't make any difference.) I know this is Wikimedia-specific because none of the fonts on other websites I visited this evening have suddenly grown in size.

Rather than rant about the habits of Wikimedia developers & their disinterest in what editors & users want -- or bore everyone by recalling how the web browser was originally intended to let end users control how they wanted content to look (which is one of the things about Wiki Wiki software I like) -- I'd like to know if there is are parameters in CSS I can apply to fix this.

Or even better, is there a resource page somewhere that documents the parameters of CSS as implemented by Wikimedia? That way I'm not uselessly repeating Frequently Asked Questions. -- llywrch (talk) 03:08, 24 June 2022 (UTC)[reply]

This seems like a (at least to me personally) previously unknown behavior of Safari/iPad wrt to viewport management. This is definetly unintentional and reproducible. I've left a note on the task that dealt with the other viewport issue earlier this week. I suspect it'll be fixed by monday. —TheDJ (talkcontribs) 06:21, 24 June 2022 (UTC)[reply]
@Llywrch, which skin/site are you using? @Jdlrobson will want to know. Whatamidoing (WMF) (talk) 17:59, 24 June 2022 (UTC)[reply]
Vector legacy (2010). I just updated the iPad OS to the latest release (15.5.1, IIRC) in an unsuccessful attempt to get Safari to handle captchas in a usable manner.
FWIW, I had a look at the latest version of Vector, & I'm not happy with replacing the options of "Talk", "Sandbox", "Preferences", etc., with icons. I just want a simple interface similar to what existed way back when without all of these "user-friendly" enhancements. (To offer my unsolicited opinion.) -- llywrch (talk) 18:10, 24 June 2022 (UTC)[reply]

Broken template[edit]

Template:Geological range (AKA Template:Fossil Range) used in Template:Taxobox is broken. See Collenia.

For future reference, where do I submit template bug reports? Where do the template gurus hang out? ILTFP (talk) 15:09, 24 June 2022 (UTC)[reply]

@Jts1882: can you take a look at this, looks like you have worked on this group of templates recently. — xaosflux Talk 15:21, 24 June 2022 (UTC)[reply]
You are in the right place, because this page is a popular home to template gurus.. 0xDeadbeef 15:25, 24 June 2022 (UTC)[reply]
Please always say what you think is wrong when you report a perceived problem. I guess you thought the green bar was in the wrong place. It was to the left of the infobox because Collenia is much older than the range in {{Geological range}}. Fixed by using {{Long fossil range}} instead per Template:Geological range#See also.[2] Maybe there should be some automation or a maintanence category for this. PrimeHunter (talk) 15:45, 24 June 2022 (UTC)[reply]
Some of these taxobox support templates have been little changed for a decade. There is also some overlap between several templates. I don't remember noticing {{Long fossil range}}. I'll try and find some time to have a look and see if we can automate or add a maintance category. —  Jts1882 | talk  17:13, 24 June 2022 (UTC)[reply]

Too many sock templates blew something up[edit]

On Wikipedia:Sockpuppet investigations/Custodi2/Archive (Special:Permalink/1093660380), something went wrong with template processing. At the bottom of the page, there's a bunch of templates which display as, for example, "Template:Checkuser" instead being interpolated. Does anybody see what's wrong there? Special:LintErrors isn't saying anything. Technically, you're not supposed to edit the SPI archives if you're not a CU or SPI Clerk, but if you know how to fix this, just go ahead. -- RoySmith (talk) 18:10, 25 June 2022 (UTC)[reply]

The NewPP limit report (view HTML source to see) shows the post‐expand include size being exceeded. Replacing {{sock list}} by something simpler like {{Bulleted list}} to show the four big lists as plain text would reduce that size by 85% and fix the problems. Certes (talk) 18:52, 25 June 2022 (UTC)[reply]
I don't know if the following workaround would exactly reproduce what {{sock list}} does. Working that out would require examining the parameters in the wikitext and deciding whether they work when used as follows. At any rate, the page renders without error after replacing each
{{sock list|1=Glenefill|2=Crainterle|...}}
with
{{#invoke:sock list|main|master=Custodi2|1=Glenefill|2=Crainterle|...}}
That halves the transclusion size. Johnuniq (talk) 00:12, 26 June 2022 (UTC)[reply]
@RoySmith: I had a closer look and it seems good, so I made the edit and the page renders correctly. Johnuniq (talk) 03:05, 26 June 2022 (UTC)[reply]
@RoySmith: {{socklist}} would have probably not been that expensive had {{checkuser}} and {{checkip}} been Lua-ified, which I just did. A quick test showed that using a module helps reducing post‐expand include size by 1,619,512 (current revision – call Module:Sock list directly) - 773,702 (replace frame:expandTemplate with its Lua equivalent) ~ 850 thousand bytes. NguoiDungKhongDinhDanh 03:51, 26 June 2022 (UTC)[reply]
Thank you everybody for your assistance. @Reaper Eternal and Tamzin: FYI. -- RoySmith (talk) 13:15, 26 June 2022 (UTC)[reply]

Flag of Arkansas.svg rendering inappropriately[edit]

Flag of Arkansas.svg

I noticed a thread in RecentChanges at Talk:Flag of Arkansas#Incorrect Flag Image?. Please see that the image at Infobox (File:Flag of Arkansas.svg, same as the rightside picture) is rendering very differently from the actual svg (/media/wikipedia/commons/9/9d/Flag_of_Arkansas.svg). Since we're talking about the Arkansan flag, all those missing stars mean that the svg when used on any page shows up a flag that is not Arkansan at all. Thanks! CX Zoom[he/him] (let's talk • {CX}) 21:22, 25 June 2022 (UTC)[reply]

Sounds like T276684. Anomie 22:09, 25 June 2022 (UTC)[reply]
Thanks Anomie! Can you (or anyone else) please raise an issue in the task? In flags, even the slightest detail matters, in this case the majority of the stars have vanished. This needs to be fixed soon. Thanks! CX Zoom[he/him] (let's talk • {CX}) 12:39, 26 June 2022 (UTC)[reply]

filtering a category[edit]

Is there an easy way to filter Category:Articles needing cleanup from June 2022 to only see entries that aren't added as having bare url? RJFJR (talk) 23:20, 25 June 2022 (UTC)[reply]

@RJFJR: I'm not sure if there is an user script that can do so directly, but you can search for them using CirrusSearch: Special:Search/deepcategory:"Articles needing cleanup from June 2022" -hastemplate:"Cleanup bare URLs". NguoiDungKhongDinhDanh 23:42, 25 June 2022 (UTC)[reply]

Petscan[edit]

Why this link doesn't works ("No result for source categories") and this one works? Eurohunter (talk) 23:50, 25 June 2022 (UTC)[reply]

As I mentioned at Wikipedia:Village pump (technical)/Archive 197#Petscan, it's an intermittent problem with petscan, it's been going on for months. --Redrose64 🌹 (talk) 06:31, 26 June 2022 (UTC)[reply]
It might be https://github.com/magnusmanske/petscan_rs/issues/106 . If not then file a bug in the same bugtracker as the link points to.--Snævar (talk) 11:44, 26 June 2022 (UTC)[reply]

Is there a way to make it harder to post death threats and other threats of harm on Wikipedia?[edit]

Looking in my inbox, I see that I have e-mailed User:Emergency twice this month: Once on Friday, and once on the 14th. On the 14th, a death threat was made in an edit summary to kill the subject of an article. This Friday, there was a threat on an admin's user subpage of killing babies (I'm not going to explain this more). Two threats this close by seems a bit dangerous. Maybe we should make an edit filter that warns users when adding something like /kill\s(him|her|the|other nouns here)/img? Maybe that'll prevent some people from adding it. weeklyd3 (message me | my contributions) 05:52, 26 June 2022 (UTC)[reply]

That would likely have a massive false positive rate. —Kusma (talk) 06:38, 26 June 2022 (UTC)[reply]
Yeah, insource:"kills him" in the search bar returns 5,256 results in article space. This is discounting the pronoun variants or the variants of the word kill. Discussions about such content may very well exist in any form of talk pages as well. So there probably would be huge false positives, if edit filter is enacted. CX Zoom[he/him] (let's talk • {CX}) 07:40, 26 June 2022 (UTC)[reply]
I expect there will be a lot in articles about crime fiction. --Redrose64 🌹 (talk) 08:13, 26 June 2022 (UTC)[reply]
This looks like the Scunthorpe problem waiting to happen.--♦IanMacM♦ (talk to me) 09:04, 26 June 2022 (UTC)[reply]

User experience for mobile users[edit]

Since yesterday (25th of June, 2022), if I open a link in Wikipedia from my mobile phone, I get to the desktop version instead of the mobile version (https://en.m.wikipedia.org). Am I the only one experiencing this? is it long term change or just a bug? I really prefer the user experience using the mobile Web interface Minerva. PAC2 (talk) 07:06, 26 June 2022 (UTC)[reply]

@PAC2 If you tap the "Mobile view" link in the page footer, does the site switch to the mobile mode? Matma Rex talk 11:38, 26 June 2022 (UTC)[reply]

Mobile not leaving edit summary and other issues[edit]

I found a couple of weird ways that editing on mobile seems to be activating a crippled version of the reply tool, where some of the most problematic things happening are being forced to publish a comment without an edit summary, and being forced to publish a comment only at the bottom of the page and nowhere else. I have documented the results of my testing, as well as instructions on how to replicate the issue over on the talk page of my sandbox. Thanks. `Huggums537 (talk) 09:04, 26 June 2022 (UTC)[reply]

@Huggums537 (I'm one of the developers) I wanted to clarify that the current mobile talk page experience is unrelated to the reply tool, and also that we're planning to replace it with the reply tool (slightly adapted to the mobile version) in the near future. I think we should have done it a while ago and I honestly don't understand why it's taking us so long to make this decision, but I hope we'll do it soon. Matma Rex talk 11:42, 26 June 2022 (UTC)[reply]