Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
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.
What I need to create a Wikipedia fork
It's been suggested that this (rather than Miscellaneous) is the place I need to ask about this. How much disk space is needed to hold a decompressed (and by what method?) download of what is available? Must the download complete without interruption or need to be restarted from scratch if something crops up? 71.105.190.154 (talk) 08:55, 10 December 2022 (UTC)
- See Wikipedia:Database download and mw:Manual:Installing MediaWiki. There are numerous ways to resume a download. — xaosflux Talk 09:15, 10 December 2022 (UTC)
- In size terms, there is a monthly update posted giving file sizes for enwiki + for one other randomly chosen dump - as of Dec 2022 it comes out as an uncompressed size of 92 GB (articles, current text only), 194 GB (all pages, current text only), and 26 TB (all pages, full history). Andrew Gray (talk) 12:06, 10 December 2022 (UTC)
- which doesnt include most of the images, since those are part of Commons (400+ TB) or wikidata which is an important part of many templates these days. —TheDJ (talk • contribs) 21:31, 10 December 2022 (UTC)
- Various articles like the forking FAQ and the Size of Wikipedia are out of date to various degrees...I am not aware of any 26TB disk drives readily available but do have multiple free bays in servers. Does Mediawiki automatically handle multiple partitions or drives or computers sharing a network file system? Are What Links Here tools readily generated from the download? 71.105.190.154 (talk) 08:41, 12 December 2022 (UTC)
- That's because it is basically not easily doable or even definable what constitutes as a fork any longer. The whole system is so large and so complex, just setting it up requires so many resources and people to manage those resources, that it's not worth describing in an FAQ. Forking is more of a theoretical possibility for a large collective of people, than a very practical thing to do. —TheDJ (talk • contribs) 13:33, 12 December 2022 (UTC)
- As I said in my earlier topic on Miscellaneous...I want a site where I have sole authority to take revisions live. I don't expect to see much traffic but I'd have satisfaction and without downloading everything I can't do triaging with maximum ability to restore deleted material and so forth.71.105.190.154 (talk) 08:26, 13 December 2022 (UTC)
- No further answers? 71.105.190.154 (talk) 09:10, 18 December 2022 (UTC)
- meta:Flagged Revisions might be what you're looking for. —CX Zoom[he/him] (let's talk • {C•X}) 09:28, 18 December 2022 (UTC)
- That's because it is basically not easily doable or even definable what constitutes as a fork any longer. The whole system is so large and so complex, just setting it up requires so many resources and people to manage those resources, that it's not worth describing in an FAQ. Forking is more of a theoretical possibility for a large collective of people, than a very practical thing to do. —TheDJ (talk • contribs) 13:33, 12 December 2022 (UTC)
- Various articles like the forking FAQ and the Size of Wikipedia are out of date to various degrees...I am not aware of any 26TB disk drives readily available but do have multiple free bays in servers. Does Mediawiki automatically handle multiple partitions or drives or computers sharing a network file system? Are What Links Here tools readily generated from the download? 71.105.190.154 (talk) 08:41, 12 December 2022 (UTC)
Section links don't work anymore
When I click through a talk page's section link in a revision history, the viewport no longer lands directly on that section in the talk page. It overshoots or undershoots and leaves me viewing some random section of the talk page; I need to reclick the section title in the TOC on the LHS in order to finally navigate there. Elizium23 (talk) 02:45, 11 December 2022 (UTC)
- @Elizium23: Always include an example. There is probably collapsible content somewhere before the section heading and during page load your browser selects a location before collapsing or expanding something above it. Also mention your skin and browser for interface and layout issues. PrimeHunter (talk) 04:21, 11 December 2022 (UTC)
- The same problem was also discovered in T325115. Navigation to sections on pages with collapsible content has always been fiddly, but I remember it working a lot more reliably until recently. I don't know right now if this is caused by a software change, or a template change. Matma Rex talk 23:02, 13 December 2022 (UTC)
This is a problem with English Wikipedia's customization that extends the handling of collapsible content provided by MediaWiki.
MediaWiki supports basically two CSS classes: mw-collapsible
to make something collapsible (but shown by default), and mw-collapsed
to also make it hidden by default. (There are some other weird options that no one uses.) mw:Manual:Collapsible elements
English Wikipedia has custom JS code that adds some other options, notably innercollapse
and outercollapse
, which allow content with the first class to be hidden by default only if it is also wrapped in the second class. Help:Collapsing#"innercollapse" and "outercollapse"
This mechanism is used by the templates generating the talk page banners: Template:WPBannerMeta/core and Template:Banner holder. This way, each WikiProject banner is made collapsible if they're wrapped in the banner holder (e.g. on Talk:Paris), but not if they aren't (e.g. Talk:Azincourt).
Generally, collapsible content in MediaWiki causes issues like this, because it is only collapsed after the page loads and JavaScript executes (to remain accessible for no-JS users), which can be after the browser has already jumped to the target section. But the mw-collapsed
class has some extremely clever styles to hide content using just CSS (T42812), which prevent the problem most of the time. innercollapse
/outercollapse
do not (the help page I linked above actually document this: "Using this technique causes the page to reflow/jump around and should generally be avoided.").
I don't really understand why this problem would pop up now. It seems that the templates and the custom JS code hasn't been changed in a while.
This could be fixed with CSS like this:
/* Avoid FOUC/reflows on collapsed elements. */
/* This copies MediaWiki's solution for T42812 to apply to innercollapse/outercollapse (T325115). */
/* Reference: https://gerrit.wikimedia.org/g/mediawiki/core/+/ecda06cb2aef55b77c4b4d7ecda492d634419ead/resources/src/jquery/jquery.makeCollapsible.styles.less#75 */
.client-js .outercollapse .innercollapse.mw-collapsible:not( .mw-made-collapsible ) > p,
.client-js .outercollapse .innercollapse.mw-collapsible:not( .mw-made-collapsible ) > table,
.client-js .outercollapse .innercollapse.mw-collapsible:not( .mw-made-collapsible ) > thead + tbody,
.client-js .outercollapse .innercollapse.mw-collapsible:not( .mw-made-collapsible ) tr:not( :first-child ),
.client-js .outercollapse .innercollapse.mw-collapsible:not( .mw-made-collapsible ) .mw-collapsible-content {
display: none;
}
This could go either in MediaWiki:Common.css (maybe around here: MediaWiki:Common.css#L-40), or somewhere in TemplateStyles of the relevant templates.
I hope someone more familiar with your customizations can pick the best place for it, but if no one responds, I could apply the changes myself (I'm a global interface editor). CC @Izno: (who touched the banner templates recently) and @TheDJ: (maintainer of the innercollapse/outercollapse code). Matma Rex talk 00:27, 14 December 2022 (UTC)
- I really want to put this in TemplateStyles as there are so few uses of the classes outside the couple of templates (innercollapse, outercollapse), and the uses in the mainspace smell funny per MOS:COLLAPSE, but I'd have to look at it closer.
- If that feels bad, use of
:is()
might be ok to put in Common.css given how this depends on JavaScript and the rule shouldn't impact old systems, then it looks like: .client-js .outercollapse .innercollapse.mw-collapsible:not( .mw-made-collapsible ) > :is(p, table, thead + tbody, tr:not( :first-child ), .mw-collapsible-content) { display: none; }
- We wouldn't be able put it in the same place as the other display: none rules either because they would flop over at the bad selector in older systems and invalidate the whole rule. Izno (talk) 00:38, 14 December 2022 (UTC)
:is()
would be okay, but the rule you posted isn't exactly equivalent (in my version some items had the>
combinator and some didn't), and as a result doesn't actually resolve the issue (testing on Talk:Paris). It probably could be tweaked, but I'd rather not mess with it.- Also, I just realized that if you use TemplateStyles, then you probably need to write
body.client-js
instead of just.client-js
to work with the auto-prefixing. (You probably know this, but saying just in case.) Matma Rex talk 01:24, 14 December 2022 (UTC)
- @Matma Rex: "I don't really understand why this problem would pop up now" Browsers defend against this kind of banner instability these days (they have some sort of page stabilitization metric, before they apply the anchor navigation). But since the Vector 2022 it seems this algorithm in the browser has a harder time detecting this situation. I haven't figured out why yet. —TheDJ (talk • contribs) 10:14, 14 December 2022 (UTC)
- Oh, that's interesting… I wonder if it's because Vector 2022 moved the sidebar HTML to the top of the source (legacy Vector has it at the bottom). That causes less visual flashing while the page loads, but it could have caused this workaround to stop working. Matma Rex talk 20:53, 14 December 2022 (UTC)
Since folks seem to be fine with my proposal but no one actually applied the fix, I applied it myself now: [1]. The issue with section links on those pages should be resolved. Matma Rex talk 19:39, 19 December 2022 (UTC)
Vector 2022 update
Hi everyone,
Once again, we want to thank all of you who have participated in discussing the new Vector 2022 skin so far, through the years of development as well as during our recent RfC. All your comments, questions, and concerns have helped us to make the skin better for readers and communities. We have a couple of updates on the skin and our plans for deployment.
Limited (fixed) width
As per the RfC closure, the "only clear blocker" to the deployment of the skin was the issue of fixed width. It was deemed insufficient to only control the width with an editor-maintained gadget. The team was tasked with building a WMF-maintained toggle, which is clearly visible and available to both logged-out and logged-in users. As a results of this, the team has:
- Built a preference for logged-in users which allows for the width to be set across pageviews and wikis. The preference is available in the appearance section of the preferences page (enable limited width mode) and may also be set as a global preference.
- Built a toggle for logged-in and logged-out users. The toggle is available on every page. Selecting the toggle increases the width of the page.
- For logged-in users, it also controls the preference mentioned in 1 above. For example, if you click the toggle on the page and visit your preferences page, you will notice that the enable limited width mode checkbox is unchecked.
- For logged-out users the toggle sets the width on a per-page basis, since preferences are not available for logged-out users. This means that after refreshing the page or opening a different page the width returns to the default state. (The lack of preferences for logged-out users doesn't only apply to this skin. You may learn more about the technical limitations.)
- Note: the toggle is still missing a tooltip, which we will be adding next week. Much thanks to those of you that pointed this out!
- We will measure how often this toggle is being used (T322772).
In addition, the team has also worked on improving the following areas of discussion and concern from the RfC:
- The language switching button not displaying languages when the compact language selector button is off (T319690) - solved
- Improving the communication for when pages are by design not connected with pages in other languages, such as talk pages (T316559) - to be completed by the end of the month
- All icons in the sticky header have tooltips that can be used to identify what each link leads to. These tooltips are also useful for accessibility purposes, specifically for screen readers.
- In our user testing, users did not experience issues with any of the available icons with the exception of the contributions icon in the user menu, which is accompanied by a text label. A/B testing of the sticky header further showed that the icons in the header are recognizable. (Use of the sticky header decreases scrolling by 15%. Edits from the edit icon have higher completion rates and lower revert rates than edits started with any other edit link or button on the page, even though the edit icon isn't accompanied by a text label.)
- Moving the page tools to the right side of the page. This change is focused on grouping the page tools clearly, and creating separation from the wiki-wide tools. It also addresses the concern for the location of the table of contents by making the sidebar (left menu) shorter and thus shifting the table of contents further up in the page. Additionally, it reduces the white space on the page by using more of the space for the display of tools.
- For those who use Vector 2022, we hope to make the updated tools menu available by the end of December, 2022. If you want to follow the development by previewing how the feature works, add
?vectorpagetools=1
to the URL (if you're using Vector 2022 already) or?useskin=vector-2022&vectorpagetools=1
(if you're not using Vector 2022).
We have added an edit button to the sticky header to make access to editing the full page easier (without requiring scrolling to the top of the page). After testing across a number of wikis, we concluded the following:
- People were more likely to complete the edits they start using the sticky header in comparison to the edits initiated using other edit buttons on the page
- The edits people started by clicking the edit button in the sticky header, and ultimately published, were reverted less often than those initiated using other edit buttons on the page
- For those who use Vector 2022, we will make the new edit button available later this week.
Next steps
Now we are ready to begin scheduling a date for the deployment of the new skin as the default on English Wikipedia. The team is currently considering January 18th as a date that will allow us enough time to sufficiently discuss the latest changes and address questions by those who have not been involved in the process so far.
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.
As we get closer to deployment, we will be reaching out with more detailed information on deployment time and any other considerations. What other considerations should we make as we get closer to deployment? We're particularly interested in ideas that will help us spread the word across logged-in users. We will certainly run banners informing logged-out and logged-in users about the change.
Comment here or meet with us this Thursday at 19:30 UTC on Discord. In the first week of January, we will also have office hours on Zoom.
Thank you all one more time for your continued time, attention, and participation! Your input has been vital to improving the new experience. OVasileva (WMF), SGrabarczuk (WMF) (talk) 20:34, 12 December 2022 (UTC)
- Thanks for the update. I may have missed it above, but I did not see a link to a list of pending bugs. Can you please point us to the list of pending bugs and feature requests so that those of us who want to try Vector 2022 again can see if little annoyances that sent us back to Vector are listed there? (Examples: I just switched temporarily, and the "More" menu and Twinkle's "TW" menu do not behave correctly for me, and the [ edit ] link for the lead section is still misplaced.) Thanks. – Jonesey95 (talk) 21:41, 12 December 2022 (UTC)
- ”do not behave correctly” in what way? (they seem to work fine for me). For open tasks, see its phabricator project https://phabricator.wikimedia.org/project/board/4281/ Vector 2022 annd the efforts surrounding it currently have some 250 open tasks, bugs, suggestions, complaints, upcoming changes, deployments etc. Note that this includes a multitude of problems that also exist in other kinds, or concern the skinning system in general. The list will never be 0. Vector legacy still has 70 open tickets after 12 years. —TheDJ (talk • contribs) 00:02, 13 December 2022 (UTC)
- Thank you for that link. After looking through the list, I have submitted three bug reports (T325038, T325037, and T325035) related to the upper-right corner of the page. I have not dug any farther than that, because I use those menus on well over half the pages that I edit. I look forward to using Vector 2022 when it is a bit more refined. Thanks for your hard work. – Jonesey95 (talk) 03:13, 13 December 2022 (UTC)
- A follow-up to TheDJ, OVasileva (WMF), and SGrabarczuk (WMF): I decided to really try to use Vector 2022, and to work to improve it for a while, instead of my usual technique of seeing that something isn't ready and grumpily going back to my stodgy old ways (Visual Editor, I'm still looking at you...). I have been using Vector 2022 for a couple of days now as my daily editor, and while the new location of some features takes some getting used to, I find it quite usable, with no real blockers as far as I have seen. All of the frustrating problems I have had with it (and continue to have, to an extent) have to do with the fundamental problem that everyone identified early in this process and that has not been fully resolved: white space. In its default configuration, and even with "Enable limited width mode" disabled, the Vector 2022 skin simply wastes too much space for it to be useful to me as a regular editor. I have submitted a few more clear bugs to try to get some of these white space problems fixed, and I have worked around other problems by making a raft of customizations in my User:Jonesey95/common.css file. I have submitted bug reports about some of them, but based on the tenor of discussions here on en.WP and in the existing bug reports, I have not yet submitted requests to fix other white space problems because I do not think they will be taken seriously or addressed in a timely fashion. Anyone is welcome to look at my CSS file and offer enhancements or submit feature requests based on them. Thank you again for communicating, and I encourage you to do so again when there are new developments and bug fixes to share. – Jonesey95 (talk) 01:11, 15 December 2022 (UTC)
- @Jonesey95 thanks for your continued feedback, and for filing specific tasks on Phabricator. Regarding "the Vector 2022 skin simply wastes too much space for it to be useful to me as a regular editor", I encourage you to be more specific (by providing annotated screenshots that point out specific issues, and maybe even comparisons with Legacy Vector, and by not generalizing...I'm not sure there is such a thing as a "regular editor"). Cheers, AHollender (WMF) (talk) 18:31, 15 December 2022 (UTC)
- Sorry, the definition of "regular" can be ambiguous. By "regular editor", I meant "someone who edits frequently, dozens to hundreds of pages per day". As that sort of editor, anything that makes me perform extra clicks or extra scrolling wastes time that is multiplied by dozens or hundreds of times each day. I hope that clarifies what I meant, and why I (and others, like Thebiguglyalien below, who is better at being concise than I am) harp on endlessly about the excessive white space. As for specifics and screen shots, please see the multiple bug reports I have filed in Phabricator, like T325219 and T325099. For some of the other issues documented in my common.css file, I am confident that they would be declined, since someone deliberately provided a "full width" mode that still has tons of padding on the left and right sides and a sidebar menu that is too wide, and someone decided to put far too much vertical white space in the sidebar TOC and to make its vertical size too small. These are design decisions made by humans who are trying to do a good job, and I have no desire to criticize them personally. Their aesthetic choices interfere with my productivity, however, so I have had to work around those choices. I'll manage one way or another, and I think that there is probably a better forum than VPT for my ravings, since my issues are no longer technical in nature. Maybe we should set up a "how to customize Vector 2022 for better productivity" page somewhere. – Jonesey95 (talk) 05:31, 16 December 2022 (UTC)
- @Jonesey95 thanks for your continued feedback, and for filing specific tasks on Phabricator. Regarding "the Vector 2022 skin simply wastes too much space for it to be useful to me as a regular editor", I encourage you to be more specific (by providing annotated screenshots that point out specific issues, and maybe even comparisons with Legacy Vector, and by not generalizing...I'm not sure there is such a thing as a "regular editor"). Cheers, AHollender (WMF) (talk) 18:31, 15 December 2022 (UTC)
- A follow-up to TheDJ, OVasileva (WMF), and SGrabarczuk (WMF): I decided to really try to use Vector 2022, and to work to improve it for a while, instead of my usual technique of seeing that something isn't ready and grumpily going back to my stodgy old ways (Visual Editor, I'm still looking at you...). I have been using Vector 2022 for a couple of days now as my daily editor, and while the new location of some features takes some getting used to, I find it quite usable, with no real blockers as far as I have seen. All of the frustrating problems I have had with it (and continue to have, to an extent) have to do with the fundamental problem that everyone identified early in this process and that has not been fully resolved: white space. In its default configuration, and even with "Enable limited width mode" disabled, the Vector 2022 skin simply wastes too much space for it to be useful to me as a regular editor. I have submitted a few more clear bugs to try to get some of these white space problems fixed, and I have worked around other problems by making a raft of customizations in my User:Jonesey95/common.css file. I have submitted bug reports about some of them, but based on the tenor of discussions here on en.WP and in the existing bug reports, I have not yet submitted requests to fix other white space problems because I do not think they will be taken seriously or addressed in a timely fashion. Anyone is welcome to look at my CSS file and offer enhancements or submit feature requests based on them. Thank you again for communicating, and I encourage you to do so again when there are new developments and bug fixes to share. – Jonesey95 (talk) 01:11, 15 December 2022 (UTC)
- Thank you for that link. After looking through the list, I have submitted three bug reports (T325038, T325037, and T325035) related to the upper-right corner of the page. I have not dug any farther than that, because I use those menus on well over half the pages that I edit. I look forward to using Vector 2022 when it is a bit more refined. Thanks for your hard work. – Jonesey95 (talk) 03:13, 13 December 2022 (UTC)
- ”do not behave correctly” in what way? (they seem to work fine for me). For open tasks, see its phabricator project https://phabricator.wikimedia.org/project/board/4281/ Vector 2022 annd the efforts surrounding it currently have some 250 open tasks, bugs, suggestions, complaints, upcoming changes, deployments etc. Note that this includes a multitude of problems that also exist in other kinds, or concern the skinning system in general. The list will never be 0. Vector legacy still has 70 open tickets after 12 years. —TheDJ (talk • contribs) 00:02, 13 December 2022 (UTC)
- The ability to toggle some of the white space is a significant improvement, but my fundamental criticism remains unchanged: reading an article in Vector 2022 provides less information in the same amount of space. In terms of screen real estate, it is effectively a downgrade. Thebiguglyalien (talk) 00:17, 13 December 2022 (UTC)
For logged-out users the toggle sets the width on a per-page basis, since preferences are not available for logged-out users. This means that after refreshing the page or opening a different page the width returns to the default state.
I don't believe this meets the requirement of the RfC. If technical limitations prevent logged out users from setting the preference for all pages, then the default should be full width. BilledMammal (talk) 00:26, 13 December 2022 (UTC)It should be possible to achieve a full-width experience using a WMF-maintained toggle, which is clearly visible and available to both logged-out and logged-in users.
- That has been provided by this implementation. Izno (talk) 00:34, 13 December 2022 (UTC)
- By requiring logged out users to click a button every single time? I don't think that complies.
- We can open another RfC on this single question - I believe a series of focused RfC's may be useful, including one on the name of the skin as there was considerable opposition to reusing Vector towards the end of the previous RfC. BilledMammal (talk) 00:59, 13 December 2022 (UTC)
By requiring logged out users to click a button every single time? I don't think that complies.
My plain reading of both this implementation and their statement is that the implementation complies. If you would like clarification from the closers over a month away from the close, that's your prerogative. I do not think they will support your opinion.We can open another RfC on this single question
Sure, if you want. I think that's a waste of time, since I think you're going to still end up with what was said in the RFC we already had, with 50% down on the ship it side with a (for some, despite a) fixed width that most of that 50% supported and 50% don't ship it side because they opposed any fixed width anywhere for any reason. The fixed width was polarizing, and you clearly have a strong opinion on the matter, but it turns out the group did not support that specific suggestion in any great plurality else we would have a closer statement saying "the fixed width must be supported on every page once selected". Izno (talk) 01:10, 13 December 2022 (UTC)- Suggested wording:
Should Vector 2022 allow logged out users to toggle the page width without requiring them to toggle it on every page?
BilledMammal (talk) 01:16, 13 December 2022 (UTC)- I can already see the answer is "no" you are describing the technical limitation described above. If you want to make an RfC, based on your previous comment it would be on changing the default from limited width to the wide variation of v22. Terasail[✉️] 01:20, 13 December 2022 (UTC)
- Technical limitations can be worked around; see this proposal that implemented such workarounds. The WMF, who wouldn't need to hack it in, could do better. BilledMammal (talk) 01:21, 13 December 2022 (UTC)
- I've opened a discussion at Village pump (idea lab). BilledMammal (talk) 01:33, 13 December 2022 (UTC)
- Technical limitations can be worked around; see this proposal that implemented such workarounds. The WMF, who wouldn't need to hack it in, could do better. BilledMammal (talk) 01:21, 13 December 2022 (UTC)
- I can already see the answer is "no" you are describing the technical limitation described above. If you want to make an RfC, based on your previous comment it would be on changing the default from limited width to the wide variation of v22. Terasail[✉️] 01:20, 13 December 2022 (UTC)
- Suggested wording:
- There are two things I don't like about the new page tools (Using vectorpagetools=1): Why is the word "Tools" repeated twice? And the text wrap of "Edit interlanguage links" when there is enough whitespace to the right of the tools box to have it on a single line. Terasail[✉️] 01:48, 13 December 2022 (UTC)
- @Terasail - thanks for the question! We're still working on the styling of the page tools (hoping to wrap up by the end of the month. Both of these issues will be resolved in the final version. OVasileva (WMF) (talk) 17:14, 13 December 2022 (UTC)
- @User:MusikAnimal: User:MusikAnimal/scriptManager.js appears to be broken with the Tool bar change. —CX Zoom[he/him] (let's talk • {C•X}) 08:08, 13 December 2022 (UTC)
- @CX Zoom All seems to work fine on my end. I tested using ?vectorpagetools=1. Could you give steps to reproduce the issue? — MusikAnimal talk 16:54, 14 December 2022 (UTC)
- @MusikAnimal: I've some 20 scripts under scriptManager but none of it shows up on appending ?useskin=vector-2022&vectorpagetools=1 , neither on the left nor on the right sidebar, and not in the Tools drop down menu either. Meanwhile, all other scripts are working fine. —CX Zoom[he/him] (let's talk • {C•X}) 17:18, 14 December 2022 (UTC)
- @CX Zoom All seems to work fine on my end. I tested using ?vectorpagetools=1. Could you give steps to reproduce the issue? — MusikAnimal talk 16:54, 14 December 2022 (UTC)
- Thank you for the width toggle! Obviously I'd like to have my preference "remembered" when I change pages, but I accept that there are many Nice Things which will never be available to IP users. Looks like two extra clicks per page will get me back to a style I like once the skin is implemented. Seems fair. 199.208.172.35 (talk) 15:27, 15 December 2022 (UTC)
- You'd think that a cookie could be used for this. Apparently not. --Redrose64 🌹 (talk) 22:35, 15 December 2022 (UTC)
- There are ways but they have corresponding drawbacks. A cookie-based solution combined with Javascript could be used, but could result in a visible shift in layout after initial page load. In theory, the caching infrastructure could be modified to serve different pages based on a cookie; if we're going to invest in that, we should probably consider what are the highest priority features we'd want to offer to non-logged in users—maybe something else is more important. Cookie-based solutions are of course client-specific, so the option wouldn't persist across different browsers. isaacl (talk) 23:13, 15 December 2022 (UTC)
- You'd think that a cookie could be used for this. Apparently not. --Redrose64 🌹 (talk) 22:35, 15 December 2022 (UTC)
- The TOC should stay where it is in Vector Legacy. Moving it upwards and moving the user tools to the right of the screen does not solve in any way the new TOC's basic problems which have been pointed out in the RfC, which seem to have been completely ignored. I propose the implementation of a hybrid TOC system like Song or Sushi, which preserves the legacy TOC along with the new one.--Æo (talk) 19:12, 19 December 2022 (UTC)
IPv6: same host, varying network
I looked at some minor edit warring at Fusil Gras mle 1874 and found these different IPs:
- 2001:fb1:14:a23d:40b8:788f:357a:8571 (talk · contribs · (/64) · deleted contribs · filter log · WHOIS · RBLs · http · block user · block log)
- 2001:fb1:14:b1f0:40b8:788f:357a:8571 (talk · contribs · (/64) · deleted contribs · filter log · WHOIS · RBLs · http · block user · block log)
- 2001:fb1:16:7d79:40b8:788f:357a:8571 (talk · contribs · (/64) · deleted contribs · filter log · WHOIS · RBLs · http · block user · block log)
Is there any logic behind the last four words (40b8:788f:357a:8571) being the same, but the last half of the first four words varying? Johnuniq (talk) 06:09, 14 December 2022 (UTC)
- Originally, there was an idea that the lower 64 bits would be for a MAC address. That was quickly discarded for obvious privacy reasons. These days, it's more likely to indicate some spoofer or VPN. Izno (talk) 06:49, 14 December 2022 (UTC)
- Actually, there are still assignment methods that would generate a stable 64-bit number for the Interface ID, as it is known. If the editor is using the same device then the Interface ID can be expected to remain stable. The varying bits in the network part can be explained by the ISP variously assigning prefixes to the same customer.
- Interface ID is often randomized for privacy these days, so it is also common to see it changing up every time an editor comes back. Elizium23 (talk) 08:04, 14 December 2022 (UTC)
- So this is more of a policy question than technical, but here's the thing: an IPv6 user just came back to a talk page to change their !vote. Their 64-bit interface ID has changed. If such an editor claims to be the same person, are they to be believed? If admins routinely block /64 networks then we are de facto treating all interface ID holders as the same person. Elizium23 (talk) 22:09, 19 December 2022 (UTC)
- I don't think we have a policy; perhaps we should. A /64 IPv6 subnet has similarities to one IPv4 address, in that it's typically shared by all users of one connection. In other ways, it differs: we can only leave User_talk: messages for the individual addresses, not the subnet. Two different IPv6 addresses within the same /64 are likely but not guaranteed to be the same person, in the same way as two edits from the same IPv4 address. Certes (talk) 13:04, 20 December 2022 (UTC)
- So this is more of a policy question than technical, but here's the thing: an IPv6 user just came back to a talk page to change their !vote. Their 64-bit interface ID has changed. If such an editor claims to be the same person, are they to be believed? If admins routinely block /64 networks then we are de facto treating all interface ID holders as the same person. Elizium23 (talk) 22:09, 19 December 2022 (UTC)
"Edit" links visually disrupted
- Vector 2022, Windows 10 Pro, Chrome Version 108.0.5359.73 (Official Build) (64-bit)
In every page I have become accustomed to the "[ edit | edit source ]" link provided at the upper-right of each section; when I click it, the editor goes into section edit mode. So far, so good. Lately after one or two WP:ITSTHURSDAYs, the edit links have been visually cut off halfway. I can only see the bottom of the text and the upper part is blanked out. See screenshot for a visual.
Elizium23 (talk) 03:25, 15 December 2022 (UTC)
- You have the align edit links right gadget on, which has caused at least one other issue that's discussed above. That gadget needs to be adjusted to support Vector22. Izno (talk) 03:36, 15 December 2022 (UTC)
- @Izno, this was fixed in Factotum by adding
line-height: 1
— Qwerfjkltalk 09:43, 15 December 2022 (UTC) - @Izno: correct, I had custom CSS in my common.css, and eliminating that line has suppressed the bug, for now. EDIT: In fact, adding
line-height: 1
has fixed it just as Qwerfjkl promised. Elizium23 (talk) 05:28, 18 December 2022 (UTC)
- @Izno, this was fixed in Factotum by adding
Image on Main Page displaying incorrectly on Firefox
On Template:Did you know, the image File:OneLove armband (transparent).png is displaying in Firefox (107.0.1, Windows 10) with a black background, rendering the text unreadable. I cannot replicate this in Chrome or Edge. Same on Firefox for mobile. Black Kite (talk) 11:41, 18 December 2022 (UTC)
- Issue now worked around by replacing it with the non-transparent version File:OneLove armband.png. Black Kite (talk) 12:23, 18 December 2022 (UTC)
- Confirmed in FF 107.0.1. It's specific to the width of 246px
- alter that to another value, like 244px
or 248px
, and it displays correctly. --Redrose64 🌹 (talk) 12:28, 18 December 2022 (UTC)
- Certainly an oddity. I've worked around it anyway by replacing it with the non-transparent version File:OneLove armband.png. Black Kite (talk) 12:31, 18 December 2022 (UTC)
- Looks the same as /Archive 201#Charles III - signature shows black background on firefox. Nardog (talk) 18:10, 18 December 2022 (UTC)
- Interestingly, the 246px verion is now showing correctly in Firefox (certainly on this page)? Black Kite (talk) 19:07, 18 December 2022 (UTC)
Edit needed to Module:Good article topics/data
Per this discussion, it seems three rows need to be added to Module:Good article topics/data. I have the template editor right and could make the edit, but I know nothing of Lua or what the possible impact of adding subtopics might be, so wanted to check here first. The rows to be added would be "culture, society, and psychology", "culture, sociology and psychology", and "culture, sociology, and psychology", all to match "soc". Mike Christie (talk - contribs - library) 14:17, 18 December 2022 (UTC)
- The module implements the mapping table described in the documentation for {{GA/Topic}}. Thus adding a new mapping will enable a new keyword to be used for a topic, without affecting any of the existing mappings in place. isaacl (talk) 15:03, 18 December 2022 (UTC)
- Thanks; I've made the edit. Mike Christie (talk - contribs - library) 18:59, 18 December 2022 (UTC)
Logged out upon switching languages
Recently I noticed when switching to another language on Wiki that I get automatically logged out, which is tedious when editing an article for an international subject and checking translations. This happens across browsers, and I believe my account should be unified. Wiki also seems to think my IP is hundreds of miles away when logged out (it shows an IP ban message), but I'm not using a VPN. Anyone else noticing this or know what is happening? Thanks. - Indefensible (talk) 19:06, 18 December 2022 (UTC)
- This is follow-up to Help talk:Logging in#Logged out upon switching languages? I believe that the reply
Logged out
to my questionWhen you return to the Wiki that you started out from - presumably English Wikipedia - are you logged in or not?
is significant. In my experience I often appear to be logged out when I go to Commons:, Meta: etc. but upon retuen to English Wikipedia, I'm still logged in. --Redrose64 🌹 (talk) 22:47, 18 December 2022 (UTC) - Problem seems to have resolved itself somehow. - Indefensible (talk) 21:31, 20 December 2022 (UTC)
How to find recent additions of a template
I am trying to find places that a template was recently added to articles. "Related changes" for the template (Special:RecentChangesLinked/Template:whatever) doesn't do it. What tool should I use? DMacks (talk) 01:16, 19 December 2022 (UTC)
- How would you define "recently" here? May be some options of comparing pagelinks of live with replicas. — xaosflux Talk 02:41, 19 December 2022 (UTC)
- This seems to be dependent on the 2014 ask in phab:T64879. — xaosflux Talk 02:42, 19 December 2022 (UTC)
- Do you know in advance what templates you want to monitor? If so then you need to compare lists of articles using the template before and after the time period, and various tools can help with that. If not then you may be out of luck, unless it's worth digging up an old database dump to analyse for the "before" list. Certes (talk) 09:45, 19 December 2022 (UTC)
- "Advanced search" at Special:Search can find the most recently edited articles with a given template but it doesn't say whether the recent edit was to add the template. Example search where 3 of the first 6 added the template. You can also write hastemplate:"Medical mnemonics" in the normal search box and add
&sort=last_edit_desc
to the url of the search results page. User:PrimeHunter/Search sort.js adds 10 links to search pages to repeat the search with sorting by different criteria. PrimeHunter (talk) 14:05, 19 December 2022 (UTC)
- "Advanced search" at Special:Search can find the most recently edited articles with a given template but it doesn't say whether the recent edit was to add the template. Example search where 3 of the first 6 added the template. You can also write hastemplate:"Medical mnemonics" in the normal search box and add
Search bar doesn't always lead directly to the searched page
For at least a year (if my memory serves me right), I've noticed that if I leave a page "untouched" in my browser for a few minutes or so, then type another article's title in the search box, it wouldn't go directly to that article, but instead to the search results page with a big banner reading "There is a page called xxx". It doesn't happen all the time, but when it does, backing to the previous page and re-searching would fix it, although sometimes I have to reload the previous page in order for it to work. It happens both on my Mac running High Sierra and my iPad running iOS 10. 2001:4453:5C6:CB00:FD89:3263:7361:56DF (talk) 10:29, 19 December 2022 (UTC)
- What do you do to submit the search? Do you press Return while the focus is on the textbox, click on the search button, click on a suggestion entry, or something else? And you're using Vector legacy, correct? Nardog (talk) 05:15, 20 December 2022 (UTC)
- I can confirm that this happens to me too on desktop site on Android. Sometimes it goes to the Special:Search page for that search term and sometimes directly to the relevant page in an unpredictable pattern. I did not really notice the "length of time page is untouched" but it could be a factor in play. —CX Zoom[he/him] (let's talk • {C•X}) 17:48, 20 December 2022 (UTC)
- Same questions as above. Nardog (talk) 23:17, 20 December 2022 (UTC)
- I almost exclusively, input something in the textbox and hit enter from keyboard to search. On Vector legacy skin. —CX Zoom[he/him] (let's talk • {C•X}) 08:53, 21 December 2022 (UTC)
- Same questions as above. Nardog (talk) 23:17, 20 December 2022 (UTC)
Optional parameter to change wording
Hello! I'm attempting to see if I can modify {{considering retirement}} to make the word "strongly" optional since you can be considering retirement but not be strongly considering it. You can see in the sandbox I've messed around a little bit to see if I can get it to do this, but I have absolutely no clue if I"m doing it right. If I'm not could I please be informed on how to do it correctly? ― Blaze WolfTalkBlaze Wolf#6545 19:02, 19 December 2022 (UTC)
- You can use
is{{#if:{{{strongly|}}}| strongly}} considering
. When someone puts|strongly=[any string here]
, the word "strongly" shows up, otherwise it won't. Bold text is already supplied byfont-weight: bold
inside the <div> container, so no need to supply it again. —CX Zoom[he/him] (let's talk • {C•X}) 19:11, 19 December 2022 (UTC)- Ah! So I was basically doing it correctly. WOuld there be a way to make it so the parameters are "yes" or "no" with the default parameter being "Yes" (just to not screw up pre-existing uses of the template, of which there are many)? ― Blaze WolfTalkBlaze Wolf#6545 19:17, 19 December 2022 (UTC)
- @Blaze Wolf,
Done with Special:Diff/1128362471, using {{Yesno-yes}}. — Qwerfjkltalk 19:19, 19 December 2022 (UTC)
- Oh wow, who knew it was that easy. ― Blaze WolfTalkBlaze Wolf#6545 19:30, 19 December 2022 (UTC)
Discussion on protected edit request for new "sortable list" tool for the Special:WhatLinksHere page
Discussion at MediaWiki talk:Linkshere#Protected edit request on 19 December 2022: add "Sorted list" external tool. Thank you! SDunlap-WMF (talk) 19:27, 19 December 2022 (UTC)
Tech News: 2022-51
MediaWiki message delivery 23:58, 19 December 2022 (UTC)
- We should probably prep some changes for Help:Show preview before that time, to take this new preview into account. —TheDJ (talk • contribs) 14:59, 21 December 2022 (UTC)
CS1 maint: unfit URL
Hi, two questions, apologies they if should be separate:
- I came across this message just now at V. C. Bird International Airport. My adblocker blocks the original URL as badware. I simply deleted the
|url-status=usurped
in this edit [9], which I think was the right thing to do. Could someone please explain the purpose of|url-status=
and the correct course of action when you find these messages? - My ref tooltips haven't been working for several days. I haven't made any changes to my Prefs→Gadgets, namely nav popups disabled and ref tooltips enabled. Any ideas, please? Cheers, MinorProphet (talk) 12:23, 20 December 2022 (UTC)
- There have been no changes to cs1|2 that have anything to do with tooltips.
|url-status=usurped
changes how a citation renders; cf:{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2022-12-20}}
- Title. Archived from the original on 2022-12-20.
{{cite book |title=Title |url=//example.com |url-status=usurped |archive-url=//archive.org |archive-date=2022-12-20}}
- The maintenance message tells interested editors why the citation renders differently from other citations.
- Your edit summary:
fix ref: rm |url-status=usurped as per CS1: maint
suggests that somewhere you found some instruction or advice that told you to remove|url-status=usurped
. Where did you find that instruction or advice? It is wrong and should be fixed. - I will revert your edit at at V. C. Bird International Airport.
- —Trappist the monk (talk) 13:51, 20 December 2022 (UTC)
- Thanks for your revert. I don't remember where I got the idea of deleting the parameter, I must have misunderstood something, sorry. Could you please explain (or point to) the purpose of
|url-status=
and the correct course of action when you find these particular messages? Some CS1 maintenance messages I can and do fix when I randomly come across them, eg CS1 maint: uses authors parameter, CS1 maint: date and year : is there anything I can do with unfit URL? Thanks, MinorProphet (talk) 16:34, 20 December 2022 (UTC)- Unfit URL is not intended to be fixed actively, so no. I am not entirely sure why it is still a maintenance category, as it's much closer to a CS1 property, but was created much earlier than the scheme we use for general tracking. Izno (talk) 17:14, 20 December 2022 (UTC)
- Thanks all for your assistance. Blue skies, MinorProphet (talk) 18:05, 20 December 2022 (UTC)
- Unfit URL is not intended to be fixed actively, so no. I am not entirely sure why it is still a maintenance category, as it's much closer to a CS1 property, but was created much earlier than the scheme we use for general tracking. Izno (talk) 17:14, 20 December 2022 (UTC)
- Thanks for your revert. I don't remember where I got the idea of deleting the parameter, I must have misunderstood something, sorry. Could you please explain (or point to) the purpose of
Template-generated categories that don't exist, re-redux
Pursuant to Wikipedia:Village_pump_(technical)/Archive_201#Template-generated_categories_that_don't_exist,_redux, {{Infobox NRHP}} is now autogenerating the equally invalid Category:Historic district contributing properties in United States New Orleans East due to the recent addition of "nrhp_type=cp" to various infoboxes. As usual, however, nonexistent categories can't stay on pages, so it has to be either created or removed, but it can't be created as "X in United States [City]" is not an appropriate naming format for a category of this type -- and, as usual, WP:TEMPLATECAT explicitly deprecates using templates to autogenerate nonexistent categories. So, again, this category-generating function has to be stripped from the infobox. Bearcat (talk) 02:13, 21 December 2022 (UTC)
- {{Infobox NRHP}} accepts
|nocat=yes
. There is an old discussion at Template talk:Infobox NRHP/Archive 4#Categorisation. PrimeHunter (talk) 03:15, 21 December 2022 (UTC)- That doesn't fix the core problem. Izno (talk) 03:40, 21 December 2022 (UTC)
- I shouldn't have to go in and add code to the infobox to make redlinked categories go away — the infobox isn't supposed to be making any redlinked categories for anybody to have to fix in the first place. Bearcat (talk) 05:50, 21 December 2022 (UTC)
- Jonesey95 didn't want to remove non-existing categories at the linked discussion. As a compromise, maybe the infobox could additionally add a maintenance category like Category:NRHP infobox adding non-existing category or use the existing Category:NRHP infobox needing cleanup. Then notify Wikipedia:WikiProject National Register of Historic Places that if nobody monitors it to fix the pages quickly then the infobox will be coded to stop adding non-existing categories. PrimeHunter (talk) 10:19, 21 December 2022 (UTC)
Gradient sigs
Hello! I'm attempting to create a signature for a user and I'm wanting to do a color gradient. Only issue is, I don't know how to create a color gradient without a crap ton of color tags which would quickly eat up the 255 character limit. Anyone know how? ― Blaze WolfTalkBlaze Wolf#6545 03:53, 21 December 2022 (UTC)
- This was doubly difficult for me, as I wanted two gradients, but after some experimenting I came up with something, although I ultimately decided not to use it as my regular signature. Here's the code for the first half:
[[User:Mandarax|<span style="color:white;background:linear-gradient(90deg,blue,red)">M<small>ANdARAX</small></span>]]
MANdARAX • XAЯAbИAM 04:13, 21 December 2022 (UTC)- That works! Thanks! ― Blaze WolfTalkBlaze Wolf#6545 04:29, 21 December 2022 (UTC)
- You're welcome. Also, since you probably only need one gradient, you could go with something more complex, such as
[[User:Mandarax|<span style="color:white;background:linear-gradient(90deg,red,orange,yellow,green,blue,purple)">M<small>ANdARAX</small></span>]]
. MANdARAX 04:36, 21 December 2022 (UTC)
- You're welcome. Also, since you probably only need one gradient, you could go with something more complex, such as
- That works! Thanks! ― Blaze WolfTalkBlaze Wolf#6545 04:29, 21 December 2022 (UTC)
- Gradients are hard to get accessible. If you really feel you must use or provide one for others to use, MDN is a good start. Izno (talk) 04:36, 21 December 2022 (UTC)
- Ew reading[Joke]Would using 2 colors that are on complete opposite sides of the color spectrum be enough to make it accessible? ― Blaze WolfTalkBlaze Wolf#6545 04:40, 21 December 2022 (UTC)
- "Opposite" colors is what makes it hard. Try finding a text color that can be placed against a gradient from black to white along the whole spectrum of that color range (good luck). OTOH, you can maybe find something between, say, purple and red (it's likely just white), or yellow and green (probably just black, depending on how dark a green). Izno (talk) 04:51, 21 December 2022 (UTC)
- Ah ok. The user requested either tech blue or red on a black background, so I figured why not make it a gradient. ― Blaze WolfTalkBlaze Wolf#6545 15:34, 21 December 2022 (UTC)
- "Opposite" colors is what makes it hard. Try finding a text color that can be placed against a gradient from black to white along the whole spectrum of that color range (good luck). OTOH, you can maybe find something between, say, purple and red (it's likely just white), or yellow and green (probably just black, depending on how dark a green). Izno (talk) 04:51, 21 December 2022 (UTC)
- I am an editor and administrator who works on Wikipedia 99% of the time on Android smartphones using the desktop site on my phone. To be honest, I simply do not understand why editors choose to use signatures that other editors cannot read or have trouble reading. Garish signatures that draw attention to me-me-me. I dislike signatures where the lower half is visible but the upper half is invisible to me. Or any other bizarre signature flourishes that are hard to read across multiple platforms. It is as if John Hancock had thrown his quill pen to the floor and signed his name to the Declaration of Independence using a lump of charcoal that he pulled out of a fireplace, making zigeddy zaggedy marks, instead of creating a beautiful signature that everyone can read and remember 250 years later. What's up with that affectation? Cullen328 (talk) 05:07, 21 December 2022 (UTC)
- Ppl feel awfully attached to standing out. As an admin and also afterwards, I've asked ppl to adapt their sigs and make them more accessible to others, but ppl don't give a flying f about it. This includes enough senior editors and fellow admins that I could not effectively enforce such polices back then. —TheDJ (talk • contribs) 09:52, 21 December 2022 (UTC)
- Although I don't actually use the above signatures (except in this thread), I don't generally object to others using such sigs unless they're particularly obnoxious or difficult to read. MANdARAX • XAЯAbИAM 23:01, 21 December 2022 (UTC)
- I'm sure I read a while back that the (then) new and upcoming talk page software wouldn't be able to do text effect sigs due to a technical limitation, meaning everyone would have to have a normal plain text sig. What ever happened to that software update? - X201 (talk) 15:47, 22 December 2022 (UTC)
- Most people hated it, and Wikipedia:Flow was uninstalled after a few trials. Some other WMF wikis (especially technical ones) still use it. —Kusma (talk) 16:21, 22 December 2022 (UTC)
- Ew reading[Joke]Would using 2 colors that are on complete opposite sides of the color spectrum be enough to make it accessible? ― Blaze WolfTalkBlaze Wolf#6545 04:40, 21 December 2022 (UTC)
I'm thinking of adopting this one as my new signature, tell me what you think:
BD2412🌈🌠🚀 B.D.2412 BD2412 BD2412B | D | 2 | 4 | 1 | 2 | ! | ! |
15:21, 22 December 2022 (UTC)
- First class. Well done. -Roxy the dog 15:56, 22 December 2022 (UTC)
- Well, it certainly has a gradient. Certes (talk) 16:29, 22 December 2022 (UTC)
- It's fine, except for the part with blue text on a golden background; I would definitely lose that part. ;-) MANdARAX • XAЯAbИAM 19:36, 22 December 2022 (UTC)
- Strong oppose, but only because the reply tool doesn't work with it. Fix that and you're good. — MusikAnimal talk 20:25, 22 December 2022 (UTC)
- @Mandarax and MusikAnimal: Thanks, I will take your comments into consideration. BD2412 T 16:07, 23 December 2022 (UTC)
WikiProject-wise edits
Would anyone be interested in creating a tool which displays user edits according to WikiProject (for example, "you've made 10 edits to WikiProject Plants, 5 edits to WikiProject Spiders, etc."). FacetsOfNonStickPans (talk) 09:40, 22 December 2022 (UTC)
- This kind of already exists, see Wikipedia:WikiProject Directory. For example, Wikipedia:WikiProject Directory/Description/WikiProject Video games. Izno (talk) 17:24, 22 December 2022 (UTC)
Anyone else finding Chrome using huge amounts of memory when watchlists added?
This just started a week ago. Doug Weller talk 14:44, 22 December 2022 (UTC)
- It continues. I've wiped out my old profile for Chrome and created a clean version, gotten rid of almost all extensions. 18 tabs including 3 watchlists and I'm at almost 7000 mb. Doug Weller talk 14:01, 23 December 2022 (UTC)
Plainlist now removed from Common.css
As a heads up, I've removed plainlist from Common.css to TemplateStyles. See MediaWiki talk:Common.css#Plainlist removed for more info. Izno (talk) 18:02, 22 December 2022 (UTC)
Unable to use VE
![](https://web.archive.org/web/20221223174506im_/https://upload.wikimedia.org/wikipedia/commons/thumb/e/ea/Purple_arrow_down.svg/20px-Purple_arrow_down.svg.png)
Hello, I am unable to to use visual editor for creating or editing article, i have done the preference setting and all what i know to make it work but its not working out and the source editor is hard for me.
Kindly help me out please QDJ22 (talk) 02:39, 23 December 2022 (UTC)
- @QDJ22: not really the best place for this question (I'd recommend somewhere like WP:VPT), but while you're here — does this link open the visual editor on WP:SANDBOX? — TheresNoTime (talk • they/them) 02:57, 23 December 2022 (UTC)
- ohh i dont know, its still the same thing on the sandbox QDJ22 (talk) 03:08, 23 December 2022 (UTC)
- @QDJ22: Odd.. do you see any errors? — TheresNoTime (talk • they/them) 03:12, 23 December 2022 (UTC)
- ohh i dont know, its still the same thing on the sandbox QDJ22 (talk) 03:08, 23 December 2022 (UTC)
- @QDJ22: What web browser and operating system are you using? Can you try loading it in a different web browser? Do you have javascript enabled? --Chris 05:37, 23 December 2022 (UTC)