Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 161.107.18.136 (talk) at 18:44, 17 January 2023 (→ConfigException: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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.

How to fix replacement character in Lua table/array?

Replacement character

Hello, on my wiki, I wanted to change "," in this line with "٬", but a question mark will appeared instead. For testing, please use {{wikidata|property|normal+|Q55|P1082}} which produces "17,942,942". According to Specials (Unicode block), U+FFFD � REPLACEMENT CHARACTER used to replace an unknown, unrecognized, or unrepresentable character". I think if it was a variable, I could handle it, but it is not. Thank you in advance! ⇒ AramTalk 13:06, 10 January 2023 (UTC)[reply]

At line 111 that module uses string.reverse(). The problem is that '٬' is a two-byte unicode character and string.reverse() operates on bytes so the two bytes that make up that character get byte-wise swapped which results in an unknown character. Unfortunately (and surprisingly) there isn't an mw.ustring.reverse() function. Perhaps as a workaround you might replace ',' with '٬' after the string has been reversed. This, I think, will require a rewrite of some or all of the reversing code. The author couldn't be bothered to document that code so why it was written as it was written is unclear. Shame, that...
—Trappist the monk (talk) 15:11, 10 January 2023 (UTC)[reply]
Reversing a Unicode string is trickier than you think, since it would have to take into account combining characters, and maybe ties, bidi characters, and so on. When I looked into it back in 2015 it seemed it would have required an additional large data table to be able to properly handle all that, which didn't seem worthwhile. As for what's going on there, it looks like it's expecting a string-encoded number as input which it then reverses to group by thousands. It could probably be written (maybe less efficiently) without reversing at all. Anomie⚔ 03:23, 11 January 2023 (UTC)[reply]
Thanks @Trappist the monk: for the explanation. Your reply made me solve it (in this way). ⇒ AramTalk 14:46, 11 January 2023 (UTC)[reply]
You could also just stick a :reverse() on the delimiter before using it in the substitution (that way, it comes out correct when re-reversed):
return left .. (num:reverse():gsub("(%d%d%d)", "%1" .. p['numeric']['delimiter']:reverse()):reverse()) .. right
Also, note that addDelimiters doesn't handle decimal separators at all... BentSm (talk) 20:40, 11 January 2023 (UTC)[reply]
@BentSm: Thanks, that was a good solution too, but in this case we also need to replace the decimal separators. Anyway, you gave me a solution for future issues. :) ⇒ AramTalk 12:25, 12 January 2023 (UTC)[reply]

Vector 2022 deployment update

Hi everyone,

Thank you all for your ongoing feedback - it has helped us make the skin better for everyone! As we previously discussed, we are preparing for the deployment of the Vector 2022 skin to all logged-out desktop users of English Wikipedia and those logged-in desktop users of English Wikipedia who both are using Vector legacy and haven't chosen Vector legacy in their global preferences. The change will take place on January 18 around 14 15:00 UTC.

We want to make the transition smooth, avoid breaking workflows, and limit confusion and post-deployment issues. We're sharing some details and useful links below to explain how the transition will be performed.

  1. This week and early next week, we'll make sure that the software version next week will be free from any easily noticeable imperfections.
  2. This week and early next week, there will be banners incentivising logged-in users to switch to Vector 2022.
  3. This week, we are also going to update affiliates such as WMCA, WMDC, WMNGA and WMUK.
  4. Shortly after the deployment, logged-out and logged-in users will see banners informing them about the change.
  5. As always, it will take at most three days for most of the cache to be updated. Before that, Vector legacy will load on some pages. After that, readers will see the new skin on any page.
  6. Before and after the deployment, we will be hosting office hours. At those meetings, we will be answering questions on the skin itself, on updating any necessary gadgets and scripts, as well as receiving feedback on future improvements to the new skin. Please, feel free to join us at the following times:

As a reminder, logged-in users can opt out at any time. Those of you using a non-default skin (Timeless, Monobook, etc) will not see any changes. If you'd like to customize the skin, here's a dedicated FAQ section.

Thank you again! OVasileva (WMF), SGrabarczuk (WMF) (talk) 19:17, 10 January 2023 (UTC)[reply]

@OVasileva (WMF) and SGrabarczuk (WMF): I missed your original update I think, but I just want to clarify with regards to icons in the sticky header: which changes were made? I see the update mentions tooltips, but I think tooltips were already there pre-RfC? Were any further changes made to these after the RfC was started? ProcrastinatingReader (talk) 13:08, 14 January 2023 (UTC)[reply]
Hey @ProcrastinatingReader, thanks for your question! We did a couple of things after the RfC to improve the sticky header:
  • Reviewed our original sticky header research on icon recognizability, specifically around the sticky header icons to confirm if there was sufficient understanding in what each icon leads to.  Users reported they were comfortable with most icons with the exception of beta features, preferences/gadgets, and contributions, all of which have labels within the user menu.
  • Accessibility tested our tooltips in collaboration with the American Foundation for the Blind
  • Worked on making the sticky header significantly more useful overall by adding a link to edit the page (which will be available in the deployment on Wednesday).  Our A/B test showed that using this new link made it more likely for people to complete the edits they start using the sticky header and that edits people initiated and published using the sticky header were less likely to be reverted.
  • Prior to the RfC we also collaborated with the Editing team on improving the sticky header on talk pages, where the icon to add a new talk page topic also contains a label “Add topic” for clarity. (For details, see the #Talk page appearance section below.)
Does that answer your question? Did you have anything specific in mind which the answer above doesn't address? Thanks,
OVasileva (WMF) & SGrabarczuk (WMF) (talk) 18:17, 14 January 2023 (UTC)[reply]

So. That notice at the top of my pages here...

The one that says

Try out the new interface improvements
Search, language switching, sticky toolbar, table of contents, and more

I have my editing all fixed-up the way I like it, so I have some questions about these changes (or "improvements"). I don't want anything about my editing to change and I don't know if I even have a choice, I just keep my head down and edit stuff around here. So do I have a choice? Is it possible to disable these "improvements" and keep editing tools/style/appearance the same as they presently are? And if editors 'can disable these upcoming changes, how do we do that? Thanks, Shearonink (talk) 16:24, 11 January 2023 (UTC)[reply]

@Shearonink This should be in reference to mw:Reading/Web/Desktop Improvements.
How to avoid this change: From reading the above, you should be able to opt out of this by setting your global skin preference to "Vector legacy (2010)" and ensuring that you do not have a "local exception on this wiki". This should mean that when the default changes, your skin will not (That is if I understand correctly). Terasail[✉️] 16:50, 11 January 2023 (UTC)[reply]
Thanks for your answer. Shearonink (talk) 17:16, 11 January 2023 (UTC)[reply]
(edit conflict) @Shearonink, you will be able to change it at Special:Preferences. See #Vector 2022 deployment update. — Qwerfjkltalk 16:52, 11 January 2023 (UTC)[reply]
Thanks for your answer. Shearonink (talk) 17:16, 11 January 2023 (UTC)[reply]
Hi @Shearonink - thanks for your question and for trying out the new interface! Have you tried out the new skin for a couple of days? We've noticed that it can take a few days for folks to get used to the new skin and the new locations of the features. That said, you can disable it at any time. There's two ways to do this - the first is the link in the left sidebar that says "Switch to old look" and the second is from the appearance section of your preferences as mentioned above. OVasileva (WMF) (talk) 16:52, 11 January 2023 (UTC)[reply]
Lol, well, actually, no I haven't tried it out, I really don't want to. Oh I know it's wonderful and whatever but what I have now *works* fine for me. And I'm going to keep it. Shearonink (talk) 17:16, 11 January 2023 (UTC)[reply]
And, strictly speaking, the editing itself shouldn't be impacted, really. All editing tools work pretty much the same way on any skin. SGrabarczuk (WMF) (talk) 17:08, 11 January 2023 (UTC)[reply]
Good to hear. When the appearance of the editing window changes I find that confusing and off-putting. I like to know where things are and am an editing creature of habit. Shearonink (talk) 17:16, 11 January 2023 (UTC)[reply]

A side question: how is this banner scheduled to pop up? Is it still going to appear after the skin is deployed? There is no way to disable this banner in the preferences. I didn't want to adblock these banners, because I would hope they are supposed to be for important announcements. But now I am seeing it 4th time already despite having dismissed it. And I have toggled to the skin and back before and I have set my preferences - why does it still show up for me at all? Where is the "don't show again" option? —  HELLKNOWZ ∣ TALK 20:02, 11 January 2023 (UTC)[reply]

Perhaps when this goes live we put up a WLN as well. — xaosflux Talk 20:09, 11 January 2023 (UTC)[reply]
Hey @Hellknowz. Thanks for this comment. Sorry for making this a bit too annoying. I've decreased the number of times the banner appears from four to three. In many cases, it's five, for example in the case of the Community Wishlist Survey or the Wikimania scholarships season. (But for the call for nominations in the steward elections, it would be three.)
These banners will not appear after the skin is deployed. We will run different banners with a different target link. Those would appear three times per user at most, I think.
I aim at some balance between making sure many people know and not pushing too much. I hope I'm close :) SGrabarczuk (WMF) (talk) 22:28, 11 January 2023 (UTC)[reply]
Well, adblock it is then ¯\_(ツ)_/¯ —  HELLKNOWZ ∣ TALK 12:01, 12 January 2023 (UTC)[reply]
@Hellknowz: That shouldn't be necessary. It's a WP:CENTRALNOTICE, so it's not difficult to write a CSS rule to hide it: 
div#DesktopImprovements_suggestion_its_coming { display: none !important; }
For English Wikipedia only, put it in Special:MyPage/common.css; for all WMF sites, put it in m:Special:MyPage/global.css. --Redrose64 🌹 (talk) 09:05, 15 January 2023 (UTC)[reply]
@Redrose64: Thanks for the suggestion. Unfortunately, the reply said "We will run different banners with a different target link" and didn't address being able to switch these off, so that won't help when something else pops up again later. —  HELLKNOWZ ∣ TALK 10:49, 15 January 2023 (UTC)[reply]

New Interface

Hi, So I decided to click the "New Interface" banner and now I regret it, Hate the new interface - it looks like the mobile version but just with more features, Is there anyway I can undo this new interface malarky ?, Thanks –Davey2010Talk 02:16, 12 January 2023 (UTC)[reply]

Took me a while but eventually found it out, I don't know why anyone thought moving the Watchlist and Contribs to the "account" icon was a fantastic idea as it wasn't. My huge dislike is the reduced page size - I don't know why things couldn't stay relatively the same as now but just upgraded but then again Facebook, Twitter and YouTube like to "improve" their designs too and ironically I never liked those redesigns either but I live with it, .Anyway not for me I'm afraid. –Davey2010Talk 02:31, 12 January 2023 (UTC)[reply]
There is a toggle width button in the right lower corner of your screen and you can change it in preferences. That way you have the new skin but the same width. Coldbolt (talk) 10:38, 14 January 2023 (UTC)[reply]
The fact that the banner changes your skin if you click on it anywhere, but the ability to change it back is obscured by that very skin, underlines that the core feature of Scalar 2022 is coercion. It is an attempt to take away the reader's control over key aspects of their experience in favour of what the WMF have internally decided is best for them, especially article width, forcing the user into a linear reading experience. All this serves to do is to assert the primacy of corporate identity and power over freedom and respect for the user. This isn't anything new though: the aesthetics of power and linearisation have been festering in social media app design for years (recently reaching a new height of evil in things like instagram stories) but it's sad that it's finally infecting Wikipedia. –small jars tc 11:13, 14 January 2023 (UTC)[reply]
The most similar case might be the old vs. new Reddit interface. I have the browser extension that auto-redirects to the old version, of course, but things are predictably starting to break and not get fixed over time (most egregiously and recently in the form of random backslashes appearing in some pasted URLs). Sooner or later, this will also happen to Vector 2010. And that's not even touching on the trend of platforms deliberately wrecking their mobile websites to goad users into using the official apps instead, which make for a much more convenient data collection and shoving-ads-down-one's-throat environment. Of course, you do need a somewhat serviceable app for that, so it probably can't become a thing for Wikipedia for at least another decade or so... Dr. Duh 🩺 (talk) 13:16, 14 January 2023 (UTC)[reply]
Well I'm using MonoBook right now without any problems, so I don't think Vector proper is ever going to stop working. The problem is that most readers have no idea that there is a way to change the skin, and the page width toggle is worthless for logged out users because it resets every time you move to a new page. If that was fixed (and it could be with session storage and common.js) I would be a little bit happier, but Scalar gets in the way of readers' control over their experience in a bunch of other ways, and editors are going to have to do a lot of work reformatting articles so they don’t look terrible in the new skin.–small jars tc 14:42, 14 January 2023 (UTC)[reply]
I hope that this high-priority bug that is tracked at Phabricator since 13 November will be fixed before 18 January 15:00 UTC. --NGC 54 (talk｜contribs) 15:11, 16 January 2023 (UTC)[reply]
Hi @NGC 54 - Thank you for bringing this up! We've been keeping a close eye on this issue as well. The bug itself is not within the Mediawiki software but is an upstream bug in Chromium browsers (affecting browsers such as Chrome , Opera, and other Chromium-based browsers). We have reached out to the Chromium team who were able to put up a couple of patches to fix the issue late last week. Progress can be tracked here. OVasileva (WMF) (talk) 15:32, 16 January 2023 (UTC)[reply]

Opinion of a reader on this design change

Hello, I just read the RfC about (way too late unfortunately). I'm French and a reader. Today I feel frustrated, not listened and betrayed by the WMF. I've been trying to voice my opinion on the Vector 2022 ever since it was forced on the French Wikipedia. I'm normally a logged-out user. Here is what I have to say, I HATE IT. I deeply feel it's one of the dumbest changes of design I've ever seen. I created an account specifically to disable that disaster when it landed on the French Wikipedia. I still remember on the French Wikipedia how there was a lot of new account that just came to know how to disable or remove it. NO ONE LIKED IT or understood why it was forced on them, but the WMF is still pushing for it, not listening, no matter what. I voiced my opinion a number of time on the discussion page, but the WMF team NEVER listen to any of the negative criticism they were given. Each time someone tried to voice a negative opinion, someone from came gave as an answer "Have read this study and our blog that explain why did that?" (yes we did thank you, and we are still not convinced) and right after that we were ignored. Since then, I have lost any trust I had in the WMF to manage Wikipedia properly. And honestly, I have the feeling some higher up at the WMF is forcing this design on everyone else and everyone is afraid to say them no. Just look at the strategy they used to push the design, first targeting a non-English-speaking Wikipedia, so people can't complain but big enough to get feedback from the few English speakers who liked it and ignoring negative feed back (like mine). Then extending to other smaller non-English-speaking Wikipedias using the same strategy, then hitting small WMF services that barely anyone uses. See how the purposefully got around their biggest Wikipedia? Now they can push this disaster on it telling you "But look a majority of the other Wikipedia use it and are happy. Sorry, but the majority has spoken." And you'll see as much as in the discussion page all negative comments will be ignored, they will impose this on the English Wikipedia as they did to the French. DerpFox (talk) 23:50, 15 January 2023 (UTC)[reply]

Hello! This page exists for people to get technical help with Wikipedia. The technical workaround for your problem, for you, is to switch to a different skin in your Preferences. It sounds like you are upset with the process; I think a page like Wikipedia:Village pump (WMF) might be a better place to address those concerns. – Jonesey95 (talk) 01:30, 16 January 2023 (UTC)[reply]
Hi. The page you are pointing me to say to come here to talk about that subject. I know I'm not really in the right place. But there don't seem to be a right place for that anywhere I look, every time I posted somewhere I've been told "no this is not the place go look at *other page name*". The WMF have made it really difficult if not impossible to voice a negative option about that new design they are forcing on every one and the way they are operating that change. DerpFox (talk) 01:57, 16 January 2023 (UTC)[reply]
The WMF is hell-bent on imposing Vector 2022 and will never listen to the community on this one. The best we can do is change skins. For logged-in registered editors, this is an easy preference change, at least for now. When logged out, I intend to use User:Alexis Jazz/SkinEnforcer. Certes (talk) 12:00, 16 January 2023 (UTC)[reply]
Indeed. Having just checked it again, I have to say I totally don't get why they changed the old "menus at top and to the left, title plus article on remainder" to "menus at top and to the left, then a title, then a new line of menu items (underlined to make it look like a subtitle), and then the remainder of the article". It's a completely counterintuitive layout. Fram (talk) 15:28, 16 January 2023 (UTC)[reply]

Going live and opting out

It seems from the above discussion that the new skin may go live on 18 January at 15:00. Is that the case? Whenever it happens, many (perhaps most) editors and readers will want to opt out of this change. Should we be more proactive in informing them of why Wikipedia looks different and how they can reverse the change if they wish? I think this needs at least a watchlist notice and possibly even a banner on the main page for the benefit of unregistered readers who have no watchlist. Certes (talk) 15:26, 16 January 2023 (UTC)[reply]

@Certes we're getting a WLN up on this. Readers won't be able to opt-out. — xaosflux Talk 15:31, 16 January 2023 (UTC)[reply]
Readers won't be able to opt-out officially, but DerpFox's comments above suggest that publicity for tools such as User:Alexis Jazz/SkinEnforcer would be very helpful. It might reduce the loss of readers to forks and mirrors which continue to use their preferred skin. Certes (talk) 19:37, 16 January 2023 (UTC)[reply]
@Certes - Thanks for your question! For logged-out users, we will also be putting banners up with more information on the change on the day of deployment. OVasileva (WMF) (talk) 15:34, 16 January 2023 (UTC)[reply]

Images and infoboxes competing for space

I'm not sure where to ask this question, perhaps if there's already a discussion, some more knowledgeable editor can link it for me here. Obviously Vector 2022 removes the table of contents from within the prose between the introduction and the first section, and this has a noticeable side effect which, similar to hiding the TOC on Vector legacy, brings the first section up, often to left of the infobox. Apparently over 3.1 million English language articles have an infobox. Many of these infoboxes are long, too long in my opinion, but that's another discussion. The end result however is, even when the "limited content width" box in the lower right is toggled on, that any images in the first section, say "History" or similar, get stacked up down the page, further and further away from their relevant prose. I work on several U.S. state articles, I'll point to Maryland, one I don't work on, as an example of this.

Help:Pictures#Avoiding stack-ups still advises me that stacking is a "problem" and gives several solutions to avoid it. I know users at WP:GAN or WP:FAC will frequently ding articles for this issue. Is stacking at the start of articles just an accepted byproduct, now that Vector 2022 will be the default? On my articles, should I do anything? Like should I avoid early images in the first sections? Should I use right-aligned tables to sit them next to infoboxes? Is there some new code coming to reduce the impact of long infoboxes? Or is all of this a moot point because desktop web browsing is dying and we should focus on how a page appears on mobile? Help, I'm very unsure here!-- Patrick Neil, oѺ∞/Talk 15:49, 16 January 2023 (UTC)[reply]

Hi @Patrickneil: Two things: On Year in xxxCountry" lists - usually with very long vertical TOC, I've changed TOC to {{horizontal TOC|nonum=yes|align=center}}. This results in the beginning content much higher on the display, even with very long right-side infobox. With that horizontal TOC there can be limit 2 or 3 to condense the TOC even more. A while back I switched (under Preferences/Appearance) to MonoBook Skin, and have not looked back to either Vector. There seem to be zero problems with MonoBook & it's quick. Second, for Avoiding stack-ups, I've seen some articles with Gallery at bottom of that section, to place 3, or 4 or 5 smaller bio images. An example is here. Also, using "right" parameter for a single image to keep the picture floating within a specific content section may be helpful. JoeNMLC (talk) 16:49, 16 January 2023 (UTC)[reply]
I raised stacking/sandwiching early on as a potential issue with removing the table of contents, and @Blaze Wolf/@Styyx raised it again during the RfC here. As far as I can tell, the developers have not weighed in.
This leaves us with basically two options. We can either decide that some sandwiching in the first section is tolerable and we can align images there to the left, or we can embark on a massive campaign to remove them. I lean toward the first option, even given that we're now working with a narrower default width, since I've never seen sandwiching as the greatest evil, and the thought of losing thousands of good images (the first section is often History, with cool historical photos) just because of this is too much to bear. I'll ping @SandyGeorgia for your thoughts, as I know sandwiching is something that comes up all the time in your FAC/FAR work. {{u|Sdkb}} talk 16:50, 16 January 2023 (UTC)[reply]
Was basically ignored because the example we gave also had a very small sandwich on the old skin, completely missing the point of the complaint. ~StyyxTalk? 16:53, 16 January 2023 (UTC)[reply]
Maybe also reconsider if anyone really benefits from having a huge list of ‘state symbols’ at such a prominent spot in an article like Maryland, pushing stuff even further down. This boyscout-level collecting of meaningless symbols, is something that few outside a subset of the USA will truly care about or need to know. ;) —TheDJ (talk • contribs) 20:31, 16 January 2023 (UTC)[reply]
Thanks Sdkb et al, glad to know that at least this was pointed out earlier. I agree that for my personal browsing, I'm unlikely to stick with Vector 2022, but I feel like I need to know how articles might display to the general public, given that the majority of their readers won't be logged in or have a vintage skin selected. I know, for example, I've been making an effort to ensure my SVGs have transparent backgrounds and colors that also work on the Wikipedia app's dark mode for Android and iOS. But after staring at this skin all day, I can't help but think that, gee, there's this big block of wasted white space on the right side of the page. The TOC and/or Wikipedia menu takes up this block on the left side, but the symmetrical space on the right is empty. So I have to ask, has anyone suggested filling that space with the page's infobox? Again, there's 6.6 million articles, and 3.1 million of them have infoboxes. Below the infobox, it can just be white space, as it is on Vector 2022 now anyways. I made myself a little animation, since I can unsee this missed opportunity now. And yep, TheDJ, I am well aware of the utter trivial-ness of that Template:Infobox U.S. state symbols, it survived a merge attempt in 2020, but if anyone was to bring it to TfD, I would surely support that!-- Patrick Neil, oѺ∞/Talk 02:05, 17 January 2023 (UTC)[reply]
Moving infoboxes to the right is non-trivial since infoboxes are an editor construct today and not a construct that the system knows about. There have been prototypes in the past that play with this positioning like mw:Winter, and I think today the responsive content gadget does some playing with some of the other elements that naturally float inline with the content on a wide resolution.
Moreover, WMF is working on "Page Tools" moving to the right hand column, see mw:Reading/Web/Desktop Improvements/Features/Page tools. Of course this doesn't preclude having an infobox there in some way.
And ultimately, we would still have the problem of decreasing resolutions which would need to allow for the infobox being inline with the content or having some other way to 'dismiss' the infobox. Izno (talk) 02:40, 17 January 2023 (UTC)[reply]
Absolutely, I hear you about how tighter resolutions would bring the infobox into the prose anyways. Perhaps, like the app though, it could collapse the infobox in line after the first paragraph on narrow resolutions. I do think though that something with this omnipresence on Wikipedia should get considered in the sites future functionality, and not just be left as an "editor construct". But that's interesting about the tools, I'm certainly learning a lot about this process now, thanks!-- Patrick Neil, oѺ∞/Talk 03:18, 17 January 2023 (UTC)[reply]
I have turned off the "show me tons of white space" option in Preferences and adjusted my own common.css to make pages display better. If there is a massive outcry about the WMF imposing all of this white space on readers and editors, perhaps we could set our default site CSS to make page content use more space. – Jonesey95 (talk) 16:26, 17 January 2023 (UTC)[reply]

I switched over to the the new Vector for a few days. Overall, I can adjust to just about everything with it, save one thing. The shade of purple used for visited links just seems too... soft... for lack of a better word. I'd like to switch back to the darker color used in the legacy Vector. I know I could add some custom CSS to switch the color. Can someone help me out? Imzadi 1979 → 20:39, 16 January 2023 (UTC)[reply]

@Patafisik (WMF), I believe French Wikipedians have this documented somewhere in the archive of their Bistro. Could you find this? Thank you! SGrabarczuk (WMF) (talk) 22:06, 16 January 2023 (UTC)[reply]
This seems to be what is calculated, you can replace the color value with whatever you want: 
a:visited {
  color: #795cb2;
}
— xaosflux Talk 22:13, 16 January 2023 (UTC)[reply]
What is the color of a visited link under the legacy Vector skin? Imzadi 1979 → 01:00, 17 January 2023 (UTC)[reply]
@Imzadi1979 it seems to be #0b0080 — xaosflux Talk 01:02, 17 January 2023 (UTC)[reply]
Thank you! Imzadi 1979 → 01:14, 17 January 2023 (UTC)[reply]
There is a closed task phab:T213778 which implemented the change but has had meaningful discussion since implementation was done that I think the team should readdress, potentially with a new task. I would guess that Femke would have some amount to say. Izno (talk) 02:34, 17 January 2023 (UTC)[reply]
Hi @Xaosflux:, the discussion on the French Wikipedia with the custom CSS is here. For further information about colors see also this explanation and this answer of AHollande (WMF).--Patafisik (WMF) (talk) 10:42, 17 January 2023 (UTC)[reply]
I found both link colors to be unreadably light, despite them apparently passing contrast tests. I added these customized colors to my common.css file, which worked for me: 
a {
    color: #0645ad
}
a:visited {
    color: #58219a;
The colors came from me testing colors on a color wheel until they felt right, not from any scientific or precedent-based process. – Jonesey95 (talk) 16:28, 17 January 2023 (UTC)[reply]
My unscientific analysis of accessibility issues (using data that may under- or overestimate this easily by a factor of 2), indicated that almost a quarter of people had some accessibility issue with the new colours, which is likely less than the old colours. There is a follow-up discussion on the phab on my talk.
I still hope a further iteration is done, as it should be feasible to at least make the link colours distinguishable for colourblind people. I think that – rather than trying to solve this ourselves – we should look for precedents and ask WebAIM if they have example colours that work. —Femke 🐦 (talk) 17:22, 17 January 2023 (UTC)[reply]

Highlighting, limit turned off?

In the past, when I have gone onto pages with complicated highlighting, the highlighting has often gone something like "Can't do highlighting in X ms, stopped trying". However now, I think I have been running into problems where it just doesn't stop. I can edit some articles, but ones like Chi Upsilon Sigma that would require compliated highlighting have frozen and in many cases crashed by browser. I turned off the replacement highlighting in preferences, but that doesn't appear to make a difference. Is there any way to either restore the limit for how long it will work on highlighting or turn it completely off? I'm working on chrome, but I've seen the same effects on other browsers, but Firefox seems just fine. Any suggestions on getting things working other than changing browsers to FF? Naraht (talk) 21:00, 10 January 2023 (UTC)[reply]

Syntax highlighting has been freezing large pages for me too recently. It's a really disruptive issue for a feature that ought to be stable at this point. {{u|Sdkb}} talk 22:02, 10 January 2023 (UTC)[reply]
I have to turn it off because I have a habit of having multiple edit pages open at the same time, which can cause my browser to freeze. It started happening to me a few weeks ago, it is a real shame since I found the feature useful. But I don't find freezing my browser regularly that useful. Terasail[✉️] 16:52, 11 January 2023 (UTC)[reply]
Terasail How do I turn it completely off? I'm currently using FF on pages that are having large amount of syntax highlighting, but would like to go back to Chrome.Naraht (talk) 14:47, 12 January 2023 (UTC)[reply]
@Naraht you should just be able to click the highligter icon in the edit toolbar, then it stays off. — xaosflux Talk 14:59, 12 January 2023 (UTC)[reply]
xaosflux no change to the light grey highlighting when I click the highlighter icon above (the one to the immediate right of the puzzle piece) Note, it isn't really working that well anyway. Everything in this section that is indented with colons is highlighted, which I don't think it is desired.Naraht (talk) 15:14, 12 January 2023 (UTC)[reply]
@Naraht is that the highlighting from disucssion tools, while you are in READING mode, or is it highlighting while you are in EDITING mode? Check in Special:Preferences#mw-prefsection-gadgets to see if you opted-in to the gadget-based highlighter, and turn that off as well. — xaosflux Talk 15:31, 12 January 2023 (UTC)[reply]
xaosflux EDITING mode (reading mode has never been a problem). I had the gadget-based highlighter set on until about a week ago until I started trying to diagnose this, but it has been turned off since, and I'm still have the problem.Naraht (talk) 15:34, 12 January 2023 (UTC)[reply]
@Naraht try loading this page in safemode, is it off there? Are you using visual editor? Which skin are you using? — xaosflux Talk 16:32, 12 January 2023 (UTC)[reply]
Xaosflux In safe mode it does not show the highlighting. I'm *not* using the Visual Editor (I've used it a bit over the previous months, it is useful for a few things, but I'm using source editor entirely now). Skin is the Vector Legacy.Naraht (talk) 20:25, 12 January 2023 (UTC)[reply]
@Naraht above the edit window, on the toolbar, to the left of where it says Advanced, what happens if you toggle that highlighter control? — xaosflux Talk 22:02, 12 January 2023 (UTC)[reply]
Xaosflux I only get that about 10%(?) of the time, most of the time I only get the two rows of icons, is there any way to force that to appear?Naraht (talk) 15:31, 13 January 2023 (UTC)[reply]
@Naraht turn off everything you have on in User:Naraht/common.js and User:Naraht/monobook.js/User:Naraht/vector-2022.js/User:Naraht/vector.js; User:Naraht/common.css, User:Naraht/vector-2022.css/User:Naraht/vector.css first; then see if it is acting consistent. If it is, you have something conflicting in one of those, you can try turning lines back on one at a time to see then. — xaosflux Talk 15:38, 13 January 2023 (UTC)[reply]
Xaosflux I've commented out everything in all 7 files and I'm still only getting the two rows of icons. (and I tested on a file in my sandbox (with reload and reload while holding down each of the "shift type" keys respecitively) Is a brand new user supposed to get the part that says advanced or do I need to click on something in the two rows of icons to see it? Also, I had "Enable the legacy (2006) editing toolbar." turned on.Naraht (talk) 15:51, 13 January 2023 (UTC)[reply]
@Naraht yse if you open this page in a "private browsing" / "incognito" / etc browser you should see it logged out, with just the default options enabled. If you want to reset all of your preferences to what a new user would have, you can do so at Special:Preferences/reset and Special:GlobalPreferences/reset. Please be aware, there is no "UNDO" of a reset there. — xaosflux Talk 16:01, 13 January 2023 (UTC)[reply]
I was trying to use the image with the highlighter to turn it off, but the image in the small box of icons on the right (orangish shape with lines through it appears to turn it on and off. While that will turn things off, it still doesn't help with the overriding issue , but if I'm concerned on a file, I'll quickly edit something small to turn it off. (This at least helps with *that* part) (and if you'd like to move this conversation to my talk page, I'm fine with that. Also, do you know what I set that vies me the double link of icons above the edit window rather than the single line that starts out B I ? I'd like to have *both* things above, since the "B I" has access to special characters and the double line of icons has find/replace.Naraht (talk) 16:05, 13 January 2023 (UTC)[reply]
Depending on which toolbar you have enabled the highlighter may be an icon that looks like this: {}. — xaosflux Talk 16:26, 13 January 2023 (UTC)[reply]
OK. So I can turn the highlighter off, and I guess that takes care of things *for now*. I do still wonder how to get both of the choices above the edit window as I mentioned just above. I'll periodically check to see if they have the highlight fixed, but I guess it isn't as serious as before since I can do that before I access complicated scripts.Naraht (talk) 18:45, 13 January 2023 (UTC)[reply]
I experience no such problem. Can you try in private mode (logged out), and report the Chrome version you are using ? (I'm using 108.0.5359.124 ) —TheDJ (talk • contribs) 20:47, 11 January 2023 (UTC)[reply]

Removal of hlist from global styles

I've just removed hlist from global styles as a part of converting to TemplateStyles. If you see an issue, please leave a comment at MediaWiki talk:Common.css#Removal of .hlist. Izno (talk) 21:29, 11 January 2023 (UTC)[reply]

Hi, My one-lined menu at User talk:Davey2010/TPMenu is broken, this is what it used to look like and now it shows as a bulleted list, Are there any fixes for this ?, Many thanks, –Davey2010Talk 21:38, 13 January 2023 (UTC)[reply]

@Davey2010: hlist has been removed from MediaWiki:Common.css. You can use {{hlist}}. PrimeHunter (talk) 21:44, 13 January 2023 (UTC)[reply]
@Davey2010 The class hlist was removed, which is why your menu broke. I went ahead and swapped this to {{Hlist}} for you. Terasail[✉️] 21:45, 13 January 2023 (UTC)[reply]
Many thanks for your help @PrimeHunter and @Terasail it's greatly appreciated and many thanks @Terasail for changing this for me, Many thanks, Warm Regards, –Davey2010Talk 22:32, 13 January 2023 (UTC)[reply]


Adding text to the beginning of a page using JavaScript Wiki Browser

The default setup for JWB always adds new text to the end of the page. I mainly use it for short descriptions, so this sometimes results in unknowingly adding a duplicate short description. Is there any way to add text to the beginning instead? Partofthemachine (talk) 00:57, 12 January 2023 (UTC)[reply]

@Partofthemachine Set it up to replace (.*) with {{Short description|Write your short description here}}$1, check the "Regular Expression" box, and put m in the "flags" box. --Ahecht (TALK
PAGE) 03:46, 12 January 2023 (UTC)[reply]
@Partofthemachine, or you could replace ^ with whatever you want to add to the beginning (^ is an anchor character meaning the start of a string). I.e. ^ → {{Short description|Write your short description here}}\n — Qwerfjkltalk 07:12, 12 January 2023 (UTC)[reply]
Yes: ^ is what I replace when adding short descriptions; it feels more efficient than slurping (.*). You can use the Skip tab to skip pages which already contain "{{short description|" (or a regex that admits spaces, uppercase S, etc.) Don't forget to remove the hidden Skip criterion before doing something else, or you may get frustrated when your next task skips half its pages! (Been there.) Certes (talk) 12:06, 12 January 2023 (UTC)[reply]
Also, as I expect you know, some templates such as infoboxes generate short descriptions automatically without needing an explicit "{{short description|..." in the article's wikitext. If you generate your lists with Cirrus search, adding -incategory:"Articles with short description" should exclude them without needing a Skip entry. — Preceding unsigned comment added by Certes (talk • contribs) 12:28, 12 January 2023 (UTC)[reply]

"Polluted" categories

Projectspace categories like Category:Lists based on Wikidata, Category:CSS image crop using invalid parameters or Category:Chem-molar-mass both hardcoded and calculated are automatically generated by maintenance templates, meaning that they're impossible to empty of draft or userspace pages that are using those maintenance templates -- so to avoid the database reports for categories with draft or userspace pages in them becoming cluttered up with permanent kludge that was impossible to resolve, Wikipedia has long had the {{polluted category}} template to flag certain categories as not of concern to category cleanup projects so that they would not get detected or listed by the cleanup reports.

However, something seems to have happened, and some categories that are tagged as "polluted category" are getting detected and listed at Wikipedia:Database reports/Polluted categories (2) despite the tag. All three of the categories I listed above, for example, are tagged as "polluted" categories, yet are listed in the current run. Could somebody investigate why this is happening, and apply whatever fixes are necessary to get these categories out of the way? Thanks. Bearcat (talk) 03:25, 12 January 2023 (UTC)[reply]

You should speak with the bot op first. Izno (talk) 04:11, 12 January 2023 (UTC)[reply]
@DannyS712: * Pppery * it has begun... 03:44, 14 January 2023 (UTC)[reply]
I'll take a look when I get a chance, sorry - I didn't know about that template before. DannyS712 (talk) 08:16, 16 January 2023 (UTC)[reply]

Talk page appearance

Just a quick note so y'all can apportion blame properly:

The Editing team is planning some changes. These will only be visible to people who have enabled the "DiscussionTools" Beta Feature. If you see them, and don't like them, they can all be turned off in Special:Preferences#mw-prefsection-editing-discussion (last item, "Show discussion activity").

The upcoming changes that you should blame on the Editing team, rather than on the Web team, are:

  • The discussion activity items that are currently visible in Talk: and User_talk: namespaces only will finally be enabled in other talk namespaces, but not in any even-numbered namespaces (e.g., the namespace this page is in).
  • The old [reply] button will become a Reply button. This is because it's easier for brand-new editors to figure out what a button is. You'll still be able to re-style it, but if you're using the old script to change it, it'll probably need to be updated.
  • [Later] They're going to add an extra "Add topic" button, so you don't have to scroll all the way back up to the top of the page to start a new section. For Vector 2022 only, this will be in its sticky header. (For all the other skins, I believe it will be at the very bottom of the page, which I guess doesn't help much if you're exactly in the middle.)
  • [Later] They're going to add a line at the top of the page, under the =Page title=, that says how long it's been since the last signed comment ("Yesterday, in the kitchen with the knife, by WhatamIdoing"). This may not be helpful on this page (and won't appear here), but it should make it easier to spot whether there are any recent conversations on a more average talk page.

Pretty much all the other visible changes this month should be blamed on my teammate Szymon. ;-)

What might be useful for Editing to hear from this group in particular is:

  • How should the software detect whether a talk page in a non-talk namespace (e.g., Help: or Wikipedia:) is the right sort of place for a discussion? If you have ideas about a reliable heuristic, I'm sure that they would be happy to hear them.

Thanks, all. Whatamidoing (WMF) (talk) 05:39, 12 January 2023 (UTC)[reply]

Is it just me or is the way that this message is worded crazy? It reads a bit like something I might post and I had to read it twice. First time I was being overwhelmed by who is blaming who? And then once to realise that this is just an annoucement of changes being made as part of mw:Talk pages project... Bit of a wild message and not the most constructive way to ask for feedback if you ask me. Terasail[✉️] 13:00, 12 January 2023 (UTC)[reply]
It reads like humorous sarcasm that was also missed on me, until i saw the winking emoticon. ~ 🦝 Shushugah (he/him • talk) 14:11, 12 January 2023 (UTC)[reply]
WMF accounts should avoid inserting humour into valid updates for communities. It will often miss and come off as some "in joke" between staff. Being clear and concise is the best way to inform people of changes but insering humour both extends the message making it less concise as well as making it less clear what the goal of posting the message is. Terasail[✉️] 15:42, 12 January 2023 (UTC)[reply]
@Terasail: It's about an upcoming interface change. Such changes always provoke posts on this (and other) pages along the lines of "I don't like it, change it back at once. Then fire the developers who foisted this on us without asking first." --Redrose64 🌹 (talk) 14:43, 12 January 2023 (UTC)[reply]
@Redrose64 While true, I run into the issue that this reads more like a "Go ahead and start complaining now at the editing team but just make sure you don't towards the web team" rather than anything particularly constructive. If the message trimmed all this finger pointing (Insert spiderman meme) that would be one thing, but it just doesn't read well for me. This would also be better if the message linked to the actual mediawiki pages which contain the explanations of each feature rather than giving long descriptions here along with coordinating some update through tech news. Terasail[✉️] 15:40, 12 January 2023 (UTC)[reply]
Unfortunately for Whatamidoing (WMF), most of us view the WMF as one big entity and do not distinguish among the teams. I can't remember ever singling out one person at WMF for criticism (if I have done so, I was probably wrong to do it), but I have leveled plenty of criticism at the organization as a whole. I know from working in large bureaucracies that many well-meaning, helpful, intelligent, and dedicated individuals can exist within an organization that often makes large errors on a regular basis. Although I think the above inter-departmental jabs were intended as humor, WMF employees would do well to remember that when the WMF does something, the WMF as a whole gets the credit or the blame, and Wikipedians generally don't care about the internal politics. – Jonesey95 (talk) 16:01, 12 January 2023 (UTC)[reply]
The regulars on this page usually care about getting their feedback, in the most efficient manner possible, to the people who can fix the problems. These are the upcoming changes that folks should complain to the Editing team about (or ping me). If it's not on this list, you probably need to contact the Web team (or ping Szymon).
I'd hoped that these changes would go out last month, to avoid this potential for confusion, but there were delays on our end, so here we are. This is your cheatsheet for which team is causing which change.
And Redrose is right, at least about someone disliking any given change and someone saying that nobody was ever asked (e.g., in the multi-month massive consultation that started this project) or informed (e.g., in Tech/News and here). There are 118,409 registered editors here at the moment. Of course some people aren't going to see these announcements. (In 2013, my team ran high-volume CentralNotice banners for two weeks about the deployment of the visual editor, and I remember someone saying that they'd missed all the banners due to being on holiday for those exact 14 days.) Of course someone's going to dislike some of these changes. Of course someone's going to dislike all of these changes. It would be patently unreasonable of me to expect that many people to agree on any UI or design point. This is normal and expected. Whatamidoing (WMF) (talk) 18:46, 12 January 2023 (UTC)[reply]
FTR I appreciated the humor, and didn't think it was too much. Chris 12:42, 14 January 2023 (UTC)[reply]

Search not working when 120% Zoomed in

Not sure whether to make Phab ticket or report here. I am using the 2022 Modern Vector skin on Firefox browser. When Zoomed in at 110%, 130% the Search icon works, but right at 120% it is not working properly. Perhaps doesn't matter, but I Zoomed in to reduce eyestrain. ~ 🦝 Shushugah (he/him • talk) 14:09, 12 January 2023 (UTC)[reply]

"not working" what does that mean. What do you see, what do you expect, what is it not doing. Screenshots would be handy perhaps. —TheDJ (talk • contribs) 14:14, 12 January 2023 (UTC)[reply]

Image thumbnail bug

Default thumbnail
Size set to 375px
Size set to 250px, which calls the 375px thumbnail if system DPI scaling is set to 150%

Does anyone know why some thumbnails sizes for some images, like File:Weekday Color.svg at 375px (direct link), are not updating? No amount of purging or reloading seems to help. --Paul_012 (talk) 16:18, 13 January 2023 (UTC)[reply]

These all look about the same to me? Is this only happening for you here on the English Wikipedia? Is it only with commonswiki files (If so have you asked over at commons:Commons:Village_pump/Technical?)? — xaosflux Talk 19:21, 13 January 2023 (UTC)[reply]
Try using the direct link. The error is with the file served by the server, so it's reproducible on every Wikimedia site. I haven't asked at Commons VP as I believe it's less frequented. But if no one here knows what's going I guess it'd need to be reported at Phabricator. --Paul_012 (talk) 14:31, 14 January 2023 (UTC)[reply]
To be fair, there was an spike of HTML status 500 from the thumbnailing system at the time (https://grafana.wikimedia.org/d/Pukjw6cWk/thumbor?orgId=1&refresh=30s&from=now-12h&to=now). Snævar (talk) 19:42, 13 January 2023 (UTC)[reply]
I still see the difference here and also via the direct link (but not via a 320px direct link, for example). The middle image is showing more-saturated colors, i.e. the previous version of the file. The file was updated on 28 November 2022 and again on 29 November 2022. Is there something that can be done to purge a cache somewhere? – Jonesey95 (talk) 21:53, 13 January 2023 (UTC)[reply]

Hmm. This appears to have since been resolve somehow. Still don't know what was going on. --Paul_012 (talk) 08:21, 17 January 2023 (UTC)[reply]

I see the correct image in all three examples now as well, and in the direct link. It looks like some sort of cache was cleared, either by an automated process, or by a gnome who read this discussion. – Jonesey95 (talk) 16:31, 17 January 2023 (UTC)[reply]

Tables and the Edit Toolbar

In all my years of editing Wikipedia, I am still not sure how to produce tables. I have been to the help pages for table construction, and that says that to produce a table, one needs to go to the Edit toolbar and select "Insert Table". This does say that this is available on Google Chrome, the search engine that got me here, but I am not sure where the Edit toolbar is. Would someone like to explain to me where one can find it? Many thanks in advance for any help. YTKJ (talk) 18:13, 13 January 2023 (UTC)[reply]

@YTKJ: We have several help pages mentioning tables and several toolbars. Please link pages you refer to. See Help:Table for general help about making tables in the source editor. In the desktop version of the site, the default toolbar for the source editor is right above the edit area and has an "Advanced" option. You can click it and then a table icon to the right to insert a table. You can also copy an existing table and modify it, or write the table code from scratch. PrimeHunter (talk) 18:44, 13 January 2023 (UTC)[reply]
See also mw:Editor. Izno (talk) 19:31, 13 January 2023 (UTC)[reply]
@YTKJ, it sounds like you're reading the directions for the visual editor. This URL should open the visual editor in your sandbox: https://en.wikipedia.org/wiki/User:YTKJ/sandbox?veaction=edit
There's a button on the far side of the toolbars that looks like a pencil, and that will let you switch back and forth between wikitext and visual editing (unless you've disabled that in your prefs). Whatamidoing (WMF) (talk) 20:47, 16 January 2023 (UTC)[reply]
Tracked in Phabricator
Task T326788
Moved from Wikipedia:Village pump (miscellaneous)

Hi, If I got to a category page (e.g. : Category:Contents), I cannot find links to the same category in other languages (e.g. fr:Catégorie:Accueil while the Wikidate item (e.g. wikidata:Q1281) lists them well ! Could someone explains me what is happening ? Thank you, Jona (talk) 16:44, 13 January 2023 (UTC)[reply]

@Jona This is a bug that seems to affect the language selection button on non-article (category, template, project...) pages on wikis using the Vector 2022 style - so English works OK but French is broken, German works OK but Danish is broken, etc. It was reported as phab:T326788; there has been a patch put out and so hopefully it should be fixed soon. Andrew Gray (talk) 18:31, 13 January 2023 (UTC)[reply]

Wikidata interlanguage linked templates not working

Tracked in Phabricator
Task T316559

There are 3 other language equivalent templates linked with Template:Diplomatic missions of Norway on Wikidata, but from en Wikipedia I get an error when selecting the language menu on top right (Vector skin 2020) Page contents not supported in other languages.. Any idea why? ~ 🦝 Shushugah (he/him • talk) 02:52, 14 January 2023 (UTC)[reply]

This is from a decision to make language switching unavailable for anything other than article space. See the phab ticket for more info. Terasail[✉️] 02:58, 14 January 2023 (UTC)[reply]
... and is being adjusted, see other task. Izno (talk) 03:00, 14 January 2023 (UTC)[reply]
Tracked in Phabricator
Task T326990

I was away for a week and now I notice that gallery mode="slideshow" is broken. See, for example, 117th United States Congress#Party summary. Same issue for 118th Congress page as well. The gallery syntax of the articles has never been changed, so it must be happening due to something else in the background. Does anyone know what went wrong, and what can be done to fix it? Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 21:21, 13 January 2023 (UTC)[reply]

@CX Zoom: It appears to only fail when both slideshow and caption are used. Simplified example: 
<gallery mode="slideshow" caption="Example">
File:Example.jpg
File:Example.png
</gallery>
You can omit caption as a workaround for now. PrimeHunter (talk) 21:39, 13 January 2023 (UTC)[reply]
I did not see an existing bug report, so I have created one. T326990. – Jonesey95 (talk) 22:09, 13 January 2023 (UTC)[reply]
Thank you very much PrimeHunter and Jonesey95. —CX Zoom[he/him] (let's talk • {C•X}) 22:34, 13 January 2023 (UTC)[reply]
I tried doing that, see Special:Diff/1133460411#Party summary, and while the resultant is better than current situation, it continues to be buggy relative to its prior behaviour. For one, the first image is huge and all others are the older size, even though they are all the equally sized svgs. A few moments ago, there appeared a vertical scrollbar for no reason. I haven't seen it before. —CX Zoom[he/him] (let's talk • {C•X}) 22:43, 13 January 2023 (UTC)[reply]
I saw this and checked the gallery I use on WP:ERT and it is also beyond broken with overflow. Its just as broken on test2 so it isn't just an enwiki issue... Terasail[✉️] 23:19, 13 January 2023 (UTC)[reply]
Resolved
 – Local css was updated. — xaosflux Talk 16:42, 16 January 2023 (UTC)[reply]

Since yesterday, section edit links in mobile web has disappeared from File namespace. Issue exists even when logged out and tried in Opera and Chrome browser Android 10 OS smartphone. I did not find this problem in other namespaces and in desktop view. The only edit button visible is the one at the top of page, which for most part is useless since it only opens the "lead section" which will be empty for most files. This has made editing file pages impossible in mobile web. The button is visible in commons and other language Wikipedias, so this seems to be something specific to English Wikipedia. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 06:47, 14 January 2023 (UTC)[reply]

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: When you click the edit button at top, the end of url contains #/editor/0. Change that to #/editor/all. This will open the entire page in editing views. A long process for a much smaller task, but until fixed, this is the workaround. —CX Zoom[he/him] (let's talk • {C•X}) 08:22, 14 January 2023 (UTC)[reply]

Log out

Right now, if you happen to click "log out", it does just that. It was also like that quite some time ago (not sure when), when I came here (I believe) to ask about a delay of some sort. I was given a solution that made it so when you clicked on "log out", a small pop-up would appear asking: "confirm you want to log out" (or something like that). It was just what I was looking for and it worked well. But I noticed today that it no longer seems to be working. I inadvertantly clicked "log out" and was immediatetly booted out. Did something change? Is it possible to still have this... fix, in place? If so, pleaae let me know what I need to do. Thank you - wolf 07:07, 14 January 2023 (UTC)[reply]

User:Guywan/Scripts/ConfirmLogout.js works for me. Stryn (talk) 10:10, 14 January 2023 (UTC)[reply]
(edit conflict) :@Thewolfchild: According to your common.js, you're useing User:Fred Gandt/confirmLogout.js, written by @Fred Gandt:. I for one am using User:Writ Keeper/Scripts/logoutConfirm.js by @Writ Keeper:, which isn't working for me either ... when I press the cancel button on the confirmation prompt, I still get logged out. I'll go and check out the working one now ... Graham87 10:14, 14 January 2023 (UTC)[reply]
Nah as a screen reader user, I prefer the prompt type that WK's script uses. A screen reader doesn't automatically focus on the confirmation prompt in the script by @Guywan:; there may well be ways to fix that on the JavaScript end but I don't know what they might be. Graham87 10:25, 14 January 2023 (UTC)[reply]
Thanks for the replies so far guys. I'll keep an eye on this thread to see if a solution comes along. Cheers - wolf 10:30, 14 January 2023 (UTC)[reply]
None of those scripts appear to support the logout link in Vector 2022's sticky header. Nardog (talk) 10:44, 14 January 2023 (UTC)[reply]
I expect there will be a lot of issues like this moving forward with Vector 2022, and updates will be needed. I'll be looking at my own; I'm always looking at my own; updating code is a constant and often tiresome need. Can we have a show of hands for folks in this thread currently using Vector 2022? Fred Gandt · talk · contribs 15:00, 14 January 2023 (UTC)[reply]

I can confirm (no pun intended) that my script is working as expected with both the Vector legacy and 2022 skins. Mine works by literally replacing the html element containing the "log out" link rather than trying to change the original's behaviour and that's what it's doing. Clicking the default link should take the user to a confirmation page anyway (something that didn't happen when I built the script back in the dark ages), so users should never get booted out by an accidental click even if they're not using one of these scripts. All that previously striked-through is rubbish. Fred Gandt · talk · contribs 15:19, 14 January 2023 (UTC)[reply]

Still using Vector legacy 2010 default. So, is there a quick-fix for this...? Cheers - wolf 15:28, 14 January 2023 (UTC)[reply]
I'm using Vector legacy and my own script and it's working as expected, so I don't know what needs fixing. Fred Gandt · talk · contribs 15:32, 14 January 2023 (UTC)[reply]
Seems I'm using the same skin and the same script, but it stopped working for me. 🤷 Don't know what to say. (Except that I do appreciate you writing that script in the first place, as well as the help it provided me for the last couple years. Thank you for that). Other than that, I hope a fix comes along soon. Cheers - wolf 15:55, 14 January 2023 (UTC)[reply]
I just rewrote the script to use the default confirmation of Special:UserLogout. By default, Wikipedia has code in place to ignore the normal confirmation process and blast users straight out the door with a hardly noticeable wave. The way I solved this problem was to completely scrap the bizarre code by replacing the log out link, then offer the "Are you sure?" confirmation. I just removed the need for the confirmation since it's already built into the default interface thus removing a step for users who actually want to log out. You should see, with my script active, when clicking the log out link, that you land on Special:UserLogout and are asked to confirm. If you don't want to log out, just go back a page in your browser history and it's like it never happened; if you want to log out, hit the big blue button and you're gone. Fred Gandt · talk · contribs 16:09, 14 January 2023 (UTC)[reply]
@Thewolfchild: you may not be aware that user scripts are not loaded on user preference pages and as such, any user script (including these log out jammers) will not function on those pages. Please confirm if User:Fred Gandt/confirmLogout.js is not functioning as described in my previous comment on non Special:Preferences pages. Cheers Fred Gandt · talk · contribs 16:27, 14 January 2023 (UTC)[reply]
When I first got booted out, I was on an article page. But anyway, I just clicked "log out" from my talk page and it worked just as you described. Thank you Fred, it's appreciated. Cheers - wolf 16:46, 14 January 2023 (UTC)[reply]
Super duper :) Fred Gandt · talk · contribs 17:00, 14 January 2023 (UTC)[reply]
In re logging yourself out: One of the things I'm liking about Vector 2022 is that the logout button is hidden in a dropdown menu. I have not ever (yet?) accidentally logged myself out while using that skin. Usually, for me, it happens when I'm clicking on Special:MyContributions just as the UTC clock gadget loads, but this isn't a problem in the new design. Whatamidoing (WMF) (talk) 20:53, 16 January 2023 (UTC)[reply]
I use a completely different method. I remove the logout link entirely (add #p-personal li#pt-logout {display: none;} to your common.css). Then, if you want to logout, you can go to your preferences and use the link there. (What I actually do is add a logout link to my toolbox. I used to frequently accidentally logout when the link was in the default location, but in many years, I've never done so from my toolbox link. And there's a confirmation dialog if I ever do misclick.) MANdARAX • XAЯAbИAM 17:14, 14 January 2023 (UTC)[reply]
@Graham87 et al.: Sorry, I've known that my logout confirm script hasn't been working for a while, but just haven't gotten around to look into it. It should be fixed now! Writ Keeper ⚇♔ 17:23, 14 January 2023 (UTC)[reply]

Ingleside, Texas

I'm not sure what to do with the history section at Ingleside, Texas. It is completely unsourced, and is nearly identical to the history on the city website. The section was added by an IP back in 2010, and the original edit included a promo for a book. I'm not sure if the section needs to be removed and nuked. Thanks! Magnolia677 (talk) 12:44, 14 January 2023 (UTC)[reply]

@Magnolia677 Wayback suggests the city website dates to 2016.[http://web.archive.org/web/20160815000000*/https://www.inglesidetx.gov/317/Ingleside-History] Doug Weller talk 14:04, 14 January 2023 (UTC)[reply]
@Doug Weller: That answers the chicken and egg question. Thanks! Magnolia677 (talk) 17:46, 14 January 2023 (UTC)[reply]

Editing window using Safari on iPad obscured

This is what I see on Safari, making it impossible to edit. Chrome doesn't have the problem. Doug Weller talk 12:03, 15 January 2023 (UTC)[reply]

Editing window using Safari on Ipad

Doug Weller talk 12:03, 15 January 2023 (UTC)[reply]

What version of hardware/software? IznoPublic (talk) 17:57, 15 January 2023 (UTC)[reply]
@Izno iPad Air, IOS15.6 which is old now, so I can't blame it on that. I'm guessing an update to Vector 2022 which I use. Doug Weller talk 13:12, 16 January 2023 (UTC)[reply]
Hey @Doug Weller, thanks for reporting this. Could you add &safemode=1 to the URL in the editing mode, and write back if you still see this issue? For me, Safari on iPad works fine but I see we're using different gadgets. SGrabarczuk (WMF) (talk) 21:36, 16 January 2023 (UTC)[reply]
iOS 15.6 is supported at both Modern and Basic levels in mw:Compatibility#Browser support matrix. At a minimum, it shouldn't look like that, so if it's still an issue in safe mode, it's something for WMF to look into. :) I'd have guessed it was display: grid that was the issue, but that looks more or less supported since iOS 10.3, so it is apparently Something Else. Izno (talk) 02:20, 17 January 2023 (UTC)[reply]
@Izno@SGrabarczuk (WMF) This is driving me a bit nuts. Adding safe mode seems to work but then at times it works without adding anything. Pretty erratic. Thanks everyone Doug Weller talk 13:38, 17 January 2023 (UTC)[reply]
If adding safe mode works, then it's about some gadget or user script you're using. SGrabarczuk (WMF) (talk) 15:35, 17 January 2023 (UTC)[reply]
Hi Doug it looks like you are loading vector-2022.js twice. You have an unnecessary line in User:Doug Weller/common.js that should be removed. That might be causing issues? Jdlrobson (talk) 16:25, 17 January 2023 (UTC)[reply]

Articles created not appearing in search results

What's good y'all.

I've noticed that since my article on Émile Reutlinger, some of the article's I have created have not been showing up in seach results (unless you type in its exact name). This also applies to the articles for Johann Eustach von Westernach, Johann Kaspar von Stadion, and Death and funeral of Pope Benedict XVI. All of them are articles that I have made that fail to appear in search results even when linking to them in other articles. There doesn't seem to be an corelary between any of them, besides that I made them and all of them, with the exception of the article on Johann Eustach von Westernach, had the under construction template on them. Is this a known issue and what can I do to combat this? Knightoftheswords281 (talk) 00:26, 3 January 2023 (UTC)[reply]

I think this is a bigger issue than just your articles. Articles that I've created after the first week in December don't show up in search results via autocomplete, until I type the complete name. – Muboshgu (talk) 20:35, 15 January 2023 (UTC)[reply]
@Knightoftheswords281 what "search results" are you looking at? The on-wiki internal search, or an external search provider? For your example of Johann Eustach von Westernach, our article is the first result both on the internal search, and from Google when I check. — xaosflux Talk 21:47, 15 January 2023 (UTC)[reply]
The internal search provider. From my experience, if you type out the full name of the article, it will appear below the search bar, however, if you even subtract or add a character, said article disappears from the search bar. Knightoftheswords281 (talk) 21:51, 15 January 2023 (UTC)[reply]
I've been noticing this as well recently. The autocomplete doesn't suggest new articles when you start typing in the search bar. HJ Mitchell | Penny for your thoughts? 21:59, 15 January 2023 (UTC)[reply]
In the past, I've seen a delay for even autopatrolled articles to appear in the search bar, but it seems to be much longer now - Macks Creek Law was created in December, and Steele's Greenville expedition at the very beginning of this month, and neither is showing up for me in the autocomplete, and both would have been autopatrolled. Hog Farm Talk 22:05, 15 January 2023 (UTC)[reply]
It used to be a delay of about a day or so. Now it's a month. – Muboshgu (talk) 02:43, 16 January 2023 (UTC)[reply]

UTF-8 ZERO WIDTH SPACE in page title

Tracked in Phabricator
Task T196088

Maybe you want to take a look at quarry:query/70555 and maybe you do not like those invisible spaces in titles. Cheers from german wikipedia (we too have ~20 of them). --Wurgl (talk) 21:21, 15 January 2023 (UTC)[reply]

@Wurgl, you might want to remove redirects. — Qwerfjkltalk 21:40, 15 January 2023 (UTC)[reply]
It looks to me like every single entry is a redirect. In that case, we don't care. * Pppery * it has begun... 21:42, 15 January 2023 (UTC)[reply]
You are right, all are redirects (i added this field to the query). --Wurgl (talk) 21:47, 15 January 2023 (UTC)[reply]

WikiProject banners visible only in preview

Tracked in Phabricator
Task T327047
Screenshots from Talk:Sharad Yadav
Broken WikiProject banner when viewing as wiki page
WikiProject banners visible in preview window

The above screenshots are taken from page Talk:Sharad Yadav in mobile web view, Opera browser, Android 10 OS. There are two WikiProject banners between {{Talk header}} and {{ITN talk}}. They are broken when viewing it as a normal wiki page and appear as two thick lines. However they render fine in the preview window. It is strange that we have software that works fine in preview but is broken in the actual page. I know there was some work on talk page banners recently before which they were completely hidden in mobile web, can something be done to fix this? ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:39, 16 January 2023 (UTC)[reply]

Thanks for the bug report, this is interesting. The issue also happens on other pages with other templates (e.g. Talk:Search coil magnetometer is another example).
I tracked down this behavior to the code that displays the "About this page" section on mobile. It (unintentionally I think) also removes some content from the "Read as wiki page" view. This happens in the code here: [1]. That's definitely a bug. I filed phab:T327047 about this.
However, that code hasn't changed in a couple of months, and I am pretty sure the templates displayed correctly before. I suspect some recent change in the templates broke some assumptions in the mobile code.
There was recent work on talk page banners, but those changes are not enabled on English Wikipedia yet. I am hoping we'll do that within a few weeks (I'm one of the developers). You can preview how the page will appear after these changes here: [2] – it doesn't suffer from this issue. Matma Rex talk 06:14, 16 January 2023 (UTC)[reply]
@Matma Rex the only recent change in the templates is the change you directed to remove the height 0 on the Signpost article talk page about mobile apps. IznoPublic (talk) 17:45, 16 January 2023 (UTC)[reply]
As for displaying correctly, this phenomenon was also discussed there. IznoPublic (talk) 17:46, 16 January 2023 (UTC)[reply]
I do not see the thick lines; I see everything as it should when "Read as wiki page" is enabled. On Chrome, Android 13. —CX Zoom[he/him] (let's talk • {C•X}) 14:02, 17 January 2023 (UTC)[reply]

Tech News: 2023-03

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

Problems

  • The URLs in "prev" links on page history now contain diff=prev&oldid=[revision ID] in place of diff=[revision ID]&oldid=[revision ID]. This is to fix a problem with links pointing to incorrect diffs when history was filtered by a tag. Some user scripts may break as a result of this change. [3]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 January. It will be on non-Wikipedia wikis and some Wikipedias from 18 January. It will be on all wikis from 19 January (calendar).
  • Some changes to the appearance of talk pages have only been available on Talk: and User talk: namespaces. These will be extended to other talk namespaces, such as Wikipedia talk:. They will continue to be unavailable in non-talk namespaces, including Wikipedia: pages (e.g., at the Village Pump). You can change your preferences (beta feature). [4]
  • On Wikisources, when an image is zoomed or panned in the Page: namespace, the same zoom and pan settings will be remembered for all Page: namespace pages that are linked to a particular Index: namespace page. [5]
  • The Vector 2022 skin will become the default for the English Wikipedia desktop users. The change will take place on January 18 at 15:00 UTC. Learn more.

Future changes

  • The 2023 edition of the Community Wishlist Survey, which invites contributors to make technical proposals and vote for tools and improvements, starts next week on 23 January 2023 at 18:00 UTC. You can start drafting your proposals in the CWS sandbox.

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

MediaWiki message delivery 01:08, 17 January 2023 (UTC)[reply]

ConfigException

Within the last hour, both of the browsers on which I'm logged in (as User:Naraht) (Chrome & FF) are giving errors that look like

MediaWiki internal error.

Original exception: [bde13a11-c59e-4e46-8642-640488f9c898] 2023-01-17 18:35:14: Fatal exception of type "ConfigException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

.

It isn't doing it on my Edge browser, but I'm not logged in there. I can't even get to the button on Chrome and FF to log out, so I'm guessing it is logged in vs. logged out, but I'm not sure.161.107.18.136 (talk) 18:44, 17 January 2023 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1134247067"