User talk here is not archived. Old talk is deleted. Users are allowed to remove anything from their talk pages. See WP:TALK and other wikipedia guidelines/policies. Like Wikipedia articles over time, people change, and there is little point in referring to past stale arguments and discussions.
To keep the discussion in one thread some comments added here are moved to the user talk page of the author. I reply there. I also watchlist that talk page for awhile in order to note when the user there replies. Harassing comments are also sometimes moved off this talk page. Sometimes the original author is offended by their own harassing comments, and my reply, on their user talk page. They then remove both from their talk page. I guess the light from their own verbal reflection offends them. One can find removed comments by using the history link on a talk page. Inappropriately-applied warning templates, etc.. are also removed from this talk page. Sometimes I remove stuff from my talk page for no particular reason, or for many varied reasons. Removal of comments from my talk page implies nothing. Don't take it personally. Unless I have requested otherwise, feel free to leave new messages on my talk page.
I had an image from Flickr from a photographer I just dealt with. He made the mistake of changing his copyright license to a Creative Commons one--but not one we accept. I took his word for it that he removed copyright in favor of Creative Commons, but since I'd just uploaded two of his photos with a correct one we accept, it was my oversight that he made a mistake and I didn't check it. The result of this was that the photo was not accepted in Commons for upload. Fine. But now I can't get the damned thing to upload it now that the license is correct! How RUDE. I've been uploading photos for years- more than any other editor I know of on the en.wikipedia. It is for this photo: [1]. How can I fix this? --Leahtwosaints (talk) 14:38, 16 August 2013 (UTC)[reply]
You have GOT to be the coolest Wikisloth with super-powers that I ever met!! For a Sloth, you sure move at a quick pace!! :) Do you wear a "super cape", I wonder? That would really complete the whole outfit and mystique.. I keep trying to think of things I could maybe do for you since you are such a blessing and a help... Hmmm. Did you ever contact Roger Ebert before his untimely demise? Is there perhaps a photo of someone that I can search for on your behalf? Just say the words. I feel a great debt to you for your help over these years. --Leahtwosaints (talk) 12:00, 17 August 2013 (UTC)[reply]
Could you believe the dark hearts won in deleting this entry? And now an article I started is also up for deletion by some nobody called LuckyLouie. --HafizHanif (talk) 21:24, 19 November 2014 (UTC)[reply]
Timeshifter, would you be able to give your honest opinion regarding the deletion of Boyd's page? I think my suggestions at the discussion are fair and at least his memory as a scientist should be in wiki, regardless of the mention of any alien stuff. --HafizHanif (talk) 20:19, 21 November 2014 (UTC)[reply]
It is interesting how other deleted pages usually have a trail of information, but Boyd's has nothing. I didn't get to read what the final verdict was ( other than obvious deletion ). --HafizHanif (talk) 21:38, 30 November 2014 (UTC)[reply]
I might have been buzzing through the disambig. page for the Van Morrison/Robbie Robertson song, "Caravan", seen here: Caravan (Van Morrison song) which they played during the filmed final concert "The Last Waltz" - if it's just my need for glasses please forgive me. Hopefully I'll have a computer soon. --Leahtwosaints (talk) 11:10, 22 April 2015 (UTC)[reply]
The WMF has been eliminating most of their talk pages (user pages and some major mainspace pages), so you're forced to use Flow if you want to contact them to discuss problems with their projects. A particular problem is that they switched over all official contacts points related to Flow itself! That is particular problem for discussing Flow bugs. (Writing about the bug *in* Flow triggers the problem!)
You've only seen the tip of the iceberg. The list of problems with Flow is 142 feet long. Copy-paste is broken. A simple revert destroyed my original comment. Problems with templates. History is a disaster. The reply-threading turns modest-size discussions into unreadable spaghetti. You can't delete your own comments, much less someone else's. (You "hide" it, which leaves a link for it on the board.) IMO the biggest issue is that Flow does not store an accurate stable copy of what you write! Flow can randomly rewrite your formatting codes and nowikis etc. The way Flow works is kind of like translating your text into Russian, then translating it from Russian back to English when someone views or edits it. Sometimes those bugs can mangle your entire post into garbage during the rewrite. In fact Flow preforms that round-trip translation every time you try to preview what you wrote. So you preview, return to editing your wikitext, and Flow has REWRITTEN your wikitext! It's like editing on quicksand. There's no "truetext", everything Flow shows you is an illusion created on the fly.
It seems the WMF still wants to eventually get Flow deployed, but the good news is that they've realized that there are serious objections here. They have been *trying* to improve their relations with the community ever since the superprotect incident, with limited success. Putting Flow on hold has been one of the successes. The current official policy is that no Flow pages will be deployed without local consensus requesting it. I think they are hoping the tiny wikis start accepting it, and that eventually all the 'obstructionist-change-averse editors' get dragged along into the wonderful future. BTW there's a doc page where "Admins" and the most "Experienced" editors are defined as the change-averse groups. Lols.
There used to be 7 Flow pages on EnWiki. Activity has dropped to zero on every board where Flow gets deployed. One board was the Flow testing board: it died and was never fixed after an admin tried testing admin tools on it. I had a pair of abandoned boards deleted at MFD. I have another abandoned board at MFD with unanimous deletes so far. I have an open RFC at a dead wikiproject to roll back Flow - I *think* its passing but running an RFC inside Flow is a disaster. We can't move the discussion posts down to a separate discussion area, it's almost impossible to tell who is replying to who, and it is difficult to figure out which posts are !votes. Anyway, assuming it passes, that will leave us with two dead Flow pages. It's possible that EnWiki will be Flow-free in a month or two. I need to contact some of the other language Wikis with Flow to see if they want to move forward with Flow or start rolling it back. Alsee (talk) 17:28, 24 December 2015 (UTC)[reply]
@Alsee: Thanks for all the info on Flow! I had to look up MFD. I see that it is Wikipedia:Miscellany for deletion. Are there any wikis using LiquidThreads still? The WMF or the devs or whoever is in charge (I have no clue), take simple requests for improvement (such as watchlisting sections of talk pages) and then go crazy with complete rewrites of all the code. Same for the request for a WYSIWYG editor. I just wanted a simple WYSIWYG editor that did the simple stuff, and did it in article sections. But they went crazy and created this monster VE that edits the whole page, and tries to do everything the wikitext editor does and more. I just want VE lite for section editing. Bold, italic, links. --Timeshifter (talk) 13:01, 26 December 2015 (UTC)[reply]
Hello, I’m Chris, a community liaison in the Discovery department at the Wikimedia Foundation. One of the projects we’re working on is to bring interactive maps to Wikipedia. If you are interested, I’d like to have an informal conversation with you about your work with WikiProject Maps, and the conventions you all have created. I'd like to learn more about your work and how that might influence the design of interactive maps.
Please let me know of some good times to chat via email and I can setup a meeting for us. I can be reached at ckoernerwikimedia.org.
If you’re not interested, that’s fine. I would appreciate any direction to other editors that have been involved and might be interested.
Hi, I don't know if there is a procedure to let people know when an editor quits to place a semi-retired placard on their talk page. In the case of Catfish Jim, one of my closest editing friends from the past, his talk page is looking like he's here, when it's just Admin and other bots that deposit info on timed intervals. To my knowledge, he hasn't been working since before I went into a coma three years ago. I think it's March 2012: [2]. I'll leave this to you as an Admin. I'm only doing little edits and am still not healed so, if you don't do something with this, I hope you'll pass it to someone who will. Thanks. --Leahtwosaints (talk) 13:09, 27 November 2016 (UTC)[reply]
As a member of WikiProject Cannabis, you are invited to help organize the project's upcoming "420" collaboration, which is scheduled for April 2017. Yes, we're a few months away, but we're hoping to get the ball rolling by getting buy-in from experienced Wikipedia editors and seek help fleshing out some goals and ideas for a successful campaign. We also plan to conduct both on-wiki and offlline outreach so non-Wikipedias can also contribute. If you are interested in participating, please sign up and contribute to the ongoing discussions. All editors are welcome! ---Another Believer(Talk)16:55, 10 January 2017 (UTC)[reply]
Hi Timeshifter, You said that you might not see my reply on Meta, so I'll talk to you here. :) I'm on the Community Tech team, and we're still working on the cross-wiki watchlist. As you saw, the cross-wiki watchlist was one of the top requests on the 2015 Community Wishlist Survey, and our team is responsible for working on it. It's still an active project for us. It's held up right now by some changes that we need to make to the database, altering the really huge and scary revision tables. We have to wait for permission and help from the database administrator to make those changes. That's a delay, which is a pain, but once we get that done, we'll keep making progress on the cross-wiki watchlist.
There's another five top wishes from last year's wishlist that we shipped last year, and we're currently working on a few top requests from this year's wishlist -- rewriting Xtools, and warning people after there have been unsuccessful login attempts. I'd be happy to tell you more about our team or the Community Wishlist, if you're interested. Let me know. -- DannyH (WMF) (talk) 23:42, 9 February 2017 (UTC)[reply]
Hey, Timeshifter, I noticed your thread at VPT. The old toolbar that you posted a screenshot of:
...is the 2006 editing toolbar, and within the last week or so, it was retired by the WMF. I'm working on reintroducing it as a user-made script, if you want it back; if you want it, you can install it by adding the line (without <code></code> tags):
Hi! I am a student editing the page Incarceration of Women in the United States. I saw that you are a main contributor to the Incarceration in the United States article, so I was wondering if you might look over my article and give me any suggestions on what more I could work on? I have mostly focused my attention on the healthcare section, but I'm hoping to submit the entire thing for good article status, so I'd appreciate any feedback you have. Please feel free to post on my talk page!
Thanks, Nicolekoonce (talk) 19:19, 13 November 2019 (UTC)[reply]
question re your ideas on editors and various items
hi. I just happened upon one of your own userboxes. i would like to try to help out. particularly with issues of editor responses, admin conduct. could you please let me know where I can help out? if you reply here, please ping me. thanks!! --Sm8900 (talk) 16:07, 16 January 2020 (UTC)[reply]
Dudley Miles. Thanks. Looks good. I adjusted and clarified a few things. Check history for explanations. I don't have MS Word. So I can't help there. I use freeware LibreOffice. Of that free office suite I only use Calc. And I am a beginner with it. --Timeshifter (talk) 17:02, 5 September 2020 (UTC)[reply]
First I noticed that you undid the revision at Template:COVID-19 pandemic death rates by country/styles.css however it doesn't seem you have implemented the changes from User:Timeshifter/Sandbox119 there yet so the table is now no longer scrolling with sticky headers. Are you still planning to re-add those features? If yes is there a reason you're waiting to implement them?
Secondly, are you looking to create a table stylesheet that can be used to implement any of these features more generally, it seems to me this might be a good idea going forward if you are aware of any feature requests that have or are likely to recur.
Apologies if this has been asked and answered elsewhere I don't really have time to read through any of those discussions in full at the moment; thanks for your help. (please ping on reply)
Update: OK I just noticed the link to Template:COVID-19 pandemic death rates on the help talk page; I presume then that this supersedes Template:COVID-19 pandemic death rates by country? If so it should probably be redirected to the new table. Second question still stands; although as I mentioned earlier it will have to be a bit before I can start on it, thanks. (please ping on reply)
Thanks for clearing that up. Well if things are moving fast I probably won't be much help. I may drop in briefly every now and then for the next 2-3 weeks but substantive projects will have to wait until towards the end of the month at least. So I'm about to log-out in a few minutes but if you hit me with a ping I'll see it sooner or later.𝒬𝔔01:11, 7 September 2020 (UTC)[reply]
Quantocius_Quantotius. I am assuming that the non-scrollable table template does not need the changes you made to it. Since those changes assumed it was a scrollable table. So I will revert your changes. Feel free to add back whatever you think is useful for a non-scrollable table. I haven't been working on that article and its template. Feel free to edit its CSS style sheet now that you know it is for a non-scrollable table.
I have been concentrating on the scrollable tables. Feel free to work on the CSS for those scrollable tables. I am a newb at CSS. I wish there was a collapse button to collapse the scrollable tables back to scrollbox size after they have been fully expanded by the "show all" button. --Timeshifter (talk) 01:27, 7 September 2020 (UTC)[reply]
Belatedly Done please see Template:COVID-19 pandemic data. Let me know if there are any issues or if there are any other templates you would like this feature added to.Sorry for the delay, had a lot more IRL stuff to attend to than I anticipated. If I do get a bit of extra time I was planning on setting up a workspace on testWP so we can try to work on some additional css features of general applicability, but I do ask for your patience. I'm already a bit overcommitted to stuff here considering the volunteer time I have available.𝒬𝔔16:16, 25 October 2020 (UTC)[reply]
(unindent). Thanks Quantocius Quantotius! There is a problem though. The collapse button only works on the template page. I just noticed this concerning "Show all" too. It works fine on the template pages. But when the 3 templates are together on COVID-19 pandemic by country and territory the buttons only work on the top template. So I guess the classes below are not specific enough. I copied the wikitext below from your recent addition to Template:COVID-19 pandemic data.
It works great on the template pages. But in the article with the 3 templates clicking any of the "show all" buttons in any table other than the top one does nothing. So the collapse buttons do not show up on the lower tables. Since they don't expand.
I created a sandbox just for you where you can experiment:
Hey, sorry you didn't like the changes to your user boxes. I was confronted with some particularly anally retentive editors when I first started editing, and they advised me that the rules and guidelines applied to all of Wikipedia, not just the articles. So, I guess that is what gave me the impression I should make the changes, but I'm just as happy to leave them the way you had them since you didn't like the changes because I'm not currently retaining my anus. LOL.😀 Huggums537 (talk) 02:22, 11 February 2021 (UTC)[reply]
Hi everyone. As I noted in the last issue, I received a grant last year from the WMF to develop the global watchlist script into an extension. That extension has now been deployed on Meta. Visit m:Special:GlobalWatchlistSettings to get started.
That grant has ended, and I have requested another grant to continue development of the extension, and figured subscribers of the newsletter about the user script might be interested. You can see and comment on the grant request at m:Grants:Project/DannyS712/Continued work on GlobalWatchlist extension - if you support this, I hope you'll consider endorsing the request.
Izno. I believe you are mistaken. Mediawiki software converts everything it sees into what it puts on the page. The browser sees none of what is in the wikitext until Mediawiki converts it to HTML, CSS, JavaScript, etc..
<ul> in the wikitext in the case of side-by-side tables and/or images contributes nothing to accessibility.
Side-by-side tables and/or images look exactly the same with or without <ul> in the wikitext.
I am not mistaken. HTML text in wikitext passes straight through the parser as HTML (both Parser.php and Parsoid) in all cases (with some HTML causing additional changes to how the parser deals with the contained text; <pre> is a notable example). That is why we have an allowed list of HTML and CSS directly in the parser as part of Sanitizer.php: we do not want bad-faith actors to use HTML elements in malevolent ways.
Subsequently, to provide valid HTML per the HTML standard, <li> must be placed inside either <ol> or <ul>, whether in an actual HTML document or a MediaWiki wikitext document. Perhaps you did not understand the point that John was making.
(N.b. I am not speaking to wikitext as wikitext just to be clear e.g. * at the beginning of a line.)
If I may butt in: if y'all are talking about this edit vs. this one, then I can definitely see a difference, in both the HTML output and the rendered output of the page. Timeshifter's edit is missing the surrounding <ul></ul> in the browser HTML, and in the rendered output (at least in my browser), the images are placed closer to the left margin. So it seems that John and Izno are correct. Writ Keeper⚇♔21:04, 15 June 2021 (UTC)[reply]
Writ Keeper. See my reply to Izno. Also, John like Izno was talking about inaccessibility problems, not the left margin. John and I discussed this elsewhere. And he did not show any inaccessibility problems. He just suspected there might be some. --Timeshifter (talk) 21:25, 15 June 2021 (UTC)[reply]
Izno. As you said everything has to go through the parser, sanitizer, etc.. And in some cases the HTML is not allowed to be used. Some deprecated HTML for example. Some works. Some doesn't.
In the case of side-by-side tables I am not seeing any inaccessibility problem. See:
In this case <ul> serves no purpose except to mess up the left margin. Someone complained about this elsewhere. Removing <ul> fixes that problem, and it is more efficient code. Less to remember.
It allows tables to fit in narrower screens too. Since there is no left margin. Narrow your browser window on the sandbox page to see. The horizontal scrollbar shows up sooner on the lower set of side-by-side tables that have <ul>
What inaccessibility problem are you seeing? I see none when doing without <ul> in this sandbox case.
Yeah, no. Bold text that indicates an argument on how your device provides you content isn't how accessibility works. "I like less code" also isn't how we make decisions where accessibility is relevant. Much less conformant HTML. If you personally cannot remember that list item elements must be inside o/ul elements, then you specifically should not revert an editor correcting that issue; if you want to fix any particular display that you do not like, you need to ask how to do that, not revert. In this case, if you want to "fix" the left margin, the way to fix that is to set margin-left: 0 on the list item elements. Izno (talk) 21:33, 15 June 2021 (UTC)[reply]
Izno. If you google style=display:inline-table you will see it used in many different ways. Many different ways without <ul>. I already knew about margin-left:0
I also already knew how to fix the problem without it. So I fixed it. You have yet to show me why my fix is incorrect. As in how it is inaccessible. --Timeshifter (talk) 21:44, 15 June 2021 (UTC)[reply]
You are barking up a totally weird tree if you think my concern has anything remotely to do with CSS display. I am strictly concerned about outputting both valid and accessible HTML, for which you must include ol/ul elements.
Izno. In my first reply to you, I mentioned screenreaders. You have yet to show me a problem with accessibility. There are many cases in wikitext that don't use the same full HTML that one would use as a webmaster. Long ago I did my share of basic web pages on Tripod, Angelfire, Geocities, etc.. So I know the difference. --Timeshifter (talk) 22:00, 15 June 2021 (UTC)[reply]
Some people use screenreaders even though they have perfect eyesight. Some developers for example. But I take your point, and I ask everybody: What accessibility problems are you claiming? If you don't have a screenreader how can you claim anything unless someone with a screenreader tells you something? Send them to User:Timeshifter/Sandbox153. Ask them if their screenreader detects any difference other than the left margin. --Timeshifter (talk) 22:06, 15 June 2021 (UTC)[reply]
Okay, first of all, it is not the responsibility of people who need accessibility aids to analyze a page for accessibility issues; it is our responsibility as editors (and as coders) to anticipate and address all such issues proactively. Second of all, look at this: [4]: specifically errors 11 and 12 (further errors suppressed). li tags are invalid HTML when used the way they are. (Granted, there are a ton of other errors, too, but that doesn't mean it's okay for us to throw a bunch more onto the pile; an analogy to WP:OTHERSTUFF comes to mind.) As Izno points out, screen readers parse the HTML structure of a page to present it to their users, and any invalid HTML can cause problems for screen readers; thus, it is incumbent on us as editors to avoid invalid HTML wherever possible, because being proactive about avoiding accessibility issues is our responsibility as editors. We should not wait until a person who depends on a screen reader to complain; if they complain, we have already failed. I don't think "I like the margin padding better" is reasonable as an excuse to use invalid HTML, especially when the same effect can be accomplished with valid HTML, and "I think the HTML looks better" is certainly not a reasonable excuse. Do better. Writ Keeper⚇♔22:30, 15 June 2021 (UTC)[reply]
I think you are making my case. There are 597 errors on that page. And additional warnings. HTML always has this problem. That is why we have transitional HTML versions, and so on. There will never be perfection.
Until we get someone with a screenreader to check out the sandbox (User:Timeshifter/Sandbox153), we are talking in circles. Mediawiki would be paralyzed if it held up everything until every single change in the mediawiki code was run by someone with a screenreader. And I have heard from someone with a screenreader who pointed out that a Mediawiki problem he experienced was annoying, but that the alternative was worse because it only helped him, but made things seriously worse for far more people. So everything is a balance. I find it annoying that you, John, and Izno are all going on strictly your suspicions, but without any evidence of a problem. I don't think there will be a problem. Screenreaders have no problem with basic tables with a single row of headers. As long as they have captions. That is what we have at User:Timeshifter/Sandbox153. See if you can round up someone with a screenreader. I will too. --Timeshifter (talk) 23:00, 15 June 2021 (UTC)[reply]
Okay, so this conversation is indeed going around in circles, but I think it's for different reasons than the ones you're thinking. You started out by saying there was no difference in the page between your version and JohnFromPinckney's version: Side-by-side tables and/or images look exactly the same with or without <ul> in the wikitext. That is demonstrably false, though; there is both a visible difference and a difference in the HTML output. When this was pointed out to you, you said In this case <ul> serves no purpose except to mess up the left margin. Someone complained about this elsewhere. Removing <ul> fixes that problem. So, now, you're saying that you see the difference (in the left margin), and are remivng UL tags deliberately to fix that. But you see how that does not correspond with what you said forty minutes earlier and ten lines above, right? You're moving the goalposts. Now, you're demanding that a person who uses a screen reader come in and prove to you that there's an accessibility issue. But it should not take a blind person with a screenreader to tell you that you're messing up the page to convince you to stop inserting invalid HTML into a page. If there are hundreds of HTML problems with a page, we don't fix it by adding ten more. And honestly, the rules of how HTML works should be the baseline for any conversation about HTML in Wikipedia, even before we get into any questions about accessibility. The burden of proof is on you to justify why you're breaking the rules of HTML, and "I don't like the margin (which can be fixed with valid HTML)" and "it's nine bytes less code" does not cut it. Writ Keeper⚇♔00:42, 16 June 2021 (UTC)[reply]
(unindent). I have been clear all along that other than the left margin, the visible output is the same. Both versions are side by side tables that wrap. Someone else on the Help:Table talk page complained about the left margin. They did not like all the clutter of using <ul style="margin-left:0px;"> to get rid of the left margin. I experimented and noticed that getting rid of <ul> altogether got rid of the left margin. This allowed side by side tables to work in narrower screens with simpler wikitext. It is all on the talk page. You keep thinking that HTML in wikitext has to follow all the rules of HTML elsewhere. According to this w3schools page <p> without </p> is malformed HTML. But Help:HTML in wikitext says: "Note that the closing tag </p> is not strictly necessary for MediaWiki installations that output HTML 5 (such as Wikipedia)." There are many other examples of allowed HTML use in wikitext that does not follow the HTML rules elsewhere.--Timeshifter (talk) 02:00, 16 June 2021 (UTC)[reply]
...Okay, I'm not sure how this isn't clear yet, but none of us are concerned about what the HTML looks like in the wikitext (i.e. in the edit box, when you're editing the page). Of course that doesn't have to be valid HTML, because it hasn't gone through the Mediawiki parser to become true HTML yet. What we're all talking about is the output HTML of the rendered page (i.e. what you see if you view the page like a reader would and right-click to view source). The edits you're making are causing errors in the output HTML, *not* the wikitext. As I explained on VPT, the example you give eith the <p> tag is not a relevant comparison. The reason the page says that the closing p tag is optional is because, when the wikitext containing an unclosed p tag goes through the Mediawiki parser, the parser will automatically close the p tag for you. So, while there is an unclosed p tag in the wikitext, there is no unclosed p tag in the output HTML, because the parser fixes it for you. But the parser does not fix orphaned li tags in the same way, so using li tags without an enclosing ul tag will lead to invalid HTML in the output HTML, not just the wikitext. You can see this in action here: https://en.wikipedia.org/w/api.php?action=parse&page=User:Writ_Keeper/sandbox . Notice how, although there is an unclosed p tag in the wikitext, the p tag is properly closed, and thus valid HTML, in the HTML code that the parser outputs. They're not the same thing. Writ Keeper⚇♔02:20, 16 June 2021 (UTC)[reply]
There is lots of other stuff that ends up in the output HTML that is not perfect HTML. Deprecated HTML, etc.. Others in the VPT thread have pointed out various examples. As I have said several times, if it doesn't effect anything then it doesn't matter. You have yet to show that this lack of <ul> here effects anything in a negative way. --Timeshifter (talk) 02:30, 16 June 2021 (UTC)[reply]
Both JAWS and NVDA detect the version with ul as containing HTML lists but do not detect the HTML lists in the version without ul. Please do not use the latter version. Also, screen readers don't normally detect margins. Graham8702:42, 16 June 2021 (UTC)[reply]
Thanks Graham. I am confused though since technically there are no lists at all in either section. There are just 2 side by side tables in each of the 2 sections.
But no problem. We no longer need that method that uses the list HTML of li and ul.
isaacl found a simpler solution that only uses divs. It is elegant, legal, and simpler. I pasted it in as a third section on that sandbox page:
Sounds good re divs. Technically there are lists in the section that contains ul ... that is exactly what the ul tag does; it creates an unordered list. Whether it's *semantically* appropriate is another thing entirely ... but a list should be marked up properly in any case. Graham8703:02, 16 June 2021 (UTC)[reply]
(unindent). Graham. So your screen readers read the divs option OK at sandbox 153? Or below? I pasted it below so that others reading this thread can check it out too.
Total number of matches played in official competitions only.
Hi!
Sorry if I'm bothering you.
I am new to Wikipedia and wanted to contribute to the site.
I noticed that the external links at the bottom of the table help page contains webpages that allows you to make tables only from inputting data directly into the website.
I was wondering if it was Ok for me to add a link to a webpage that makes tables that allows user to upload excel files and convert it to the wiki format and vice versa.
Thanks!
--Rangusangus (talk) 17:12, 1 July 2021 (UTC)[reply]
Rangusangus. What is the link? I will have a look at it. It might also be posted here:
@Timeshifter: I have used this converter before and can confirm that it works. Personally, I find it more convenient than the other converters, especially for larger tables as it requires a file upload than copy pasting. It also has options for single quote and double quote tables.
I managed to contact them and they said the scroll button should be fixed now.
For the loading problems, I don't have a problem on my end so it might be a geographical issue where the webpage is hosted.
It no longer is messed up. But it takes 20 seconds to load. Please ask them to remove as much external styling and scripting as possible. Try using inline styling instead. It is just a simple web page, and shouldn't take 20 seconds to load. --Timeshifter (talk) 05:46, 7 July 2021 (UTC)[reply]
@Timeshifter: They said there were a minimal amount of external styling and scripting and there was nothing too fancy.
I tried to test the website on 2 speed checking website and the average load time was 0.5 seconds. https://imgur.com/a/ilrc8Ub
Hello :)
I am writing my MA dissertation on Wikipedia Wars and the Israel-Palestine conflict, and I noticed that you have contributed to those pages. My dissertation will look at the process of collaborative knowledge production on the Israel-Palestine conflict, and the effect it has on bias in the articles. This will involve understanding the profiles and motivations of editors, contention/controversy and dispute resolution in the talk pages, and bias in the final article.
For more information, you can check out my meta-wiki research page or my user page, where I will be posting my findings when I am done.
I would greatly appreciate if you could take 5 minutes to fill out this quick surveybefore 8 August 2021.
Participation in this survey is entirely voluntary and anonymous. There are no foreseeable risks nor benefits to you associated with this project.
For example: "Around 100,300 died in the 12 month period ending April 30, 2021.[4] That's 275 a day."
Would you agree that this declarative "That's 275 a day" seems a bit informal? Would it bother you if I changed the lead to something like "Around 100,300 people died in the 12 month period ending April 30, 2021, at a rate of 275 deaths per day.[4]"? I don't want to ask you to do anything because I know you're such a busy contributor.
WikiCleanerMan. I just changed its name to User:Timeshifter/Sandbox176. It is referenced in some important technical discussions concerning scrollable tables with sticky headers. Both row and column sticky headers. Narrow your browser window to see what I mean.
I am hoping I am doing this correctly. I saw your comments on Raw Story and agree with them.I am sorry but I do not have an account and hope this is the correct place to respond. I will also answer you on the other page.
Can you PLEASE --- whenever you have time take a look at Palmer Report? There has been a Wikipedia attack from some republican editors. They are a political site -- a good one and I am a fan.
For months (years) scores of people have been pleading with the editors there to take the "hyper partisan, fake news website" out of the header. It is not accurate. It was put there by the same person who muddied up Raw story -- a republican. I along with dozens -- literally dozens of people protested. We felt it was an attack, a vicious one. The response was always send some reliable sources to counter it.
Only nobody ever used the term "hyper-partisan, fake news website" in the first place. I spent four hours trying to find a source and asked several times. There are some obscure republican sources. They never used, to the best of my knowledge any of those terms.
They also locked the page when people tried to change it and called it vandalism. But everyone I saw came in good faith. The Palmer Report is not fake news and is very much like Raw Story. I had a source -- Brian Williams from MSNBC did a segment several tears ago and used information from their site. I was told that was not interesting enough to put on the site and then they ignored me and all the others. You an easily see this through old Talk pages because there are over a dozen complaints.
I hope you are not upset that I posted such a long post but I think what is happening makes Wiki look very bad and I liked what you said on the raw story site. I do not want to name the person less it be thought of as a verbal attack but you can see all this quite easily. Please if you can do anything, please research this and please look seriously at the "hyperpartisan, fake news" entry. Because that is not neutral.
Hi Norah. I don't have the time, health, and energy nowadays for much Wikipedia activity. You will get a lot farther if you log in with a user name. You are still anonymous. You can create an account with just a user name and password. Email address is optional, and is not public. Useful for password resets. It can be a secondary throwaway email address. Gmail can be set to forward to another email address. Even another Gmail address. --Timeshifter (talk) 00:59, 7 February 2023 (UTC)[reply]
Thank you. I am sorry about your health issues. I will not bore you with a long reply but I have tried in the past as have others and nothing worked. Was delighted to see how several of you fixed Raw Story who I also like. But I am completely unaware of how to edit on Wiki and also have some (minor) health issues. But thanks! At least you care and that counts for a lot. I hope your health situation improves and thank you so much for answering.
The Editing team is beginning a project to help new editors of Wikipedia. It will help people identify some problems before they click "Publish changes". The first tool will encourage people to add references when they add new content. Please watch that page for more information. You can join a conference call on 3 March 2023 to learn more.
Hello! Was looking into some of the history of and proposals for a global watchlist, and saw quite a few comments on it by you in the past. Is there a current solution or commonly accepted tooling for this purpose? Thanks! Top5a (talk) 06:49, 27 May 2023 (UTC)[reply]
I realize we have been butting heads (in good faith!) a bunch recently. But I wanted to stop by and just say I appreciate the work you do maintaining tables across the website, ensuring text-citation integrity, and helping others understand how to maintain the encyclopedia. Thank you, and happy new year! Enjoy this stroopwafel – I saw "stroopwafel" in the WikiLove menu and needed to see what one is. They look delicious, but I can't say I've heard of one before, much less tried one :)
Hello everyone, and welcome to the 24th issue of the Wikipedia Scripts++ Newsletter, covering all our favorite new and updated user scripts since 24 December 2021. Uh-huh, we're finally covering the good ones among the rest! Aren't you excited? Remember to include a link in double brackets to the script's .js page when you install the script, so that we can see who uses the script in WhatLinksHere! The ScriptInstaller gadget automatically does this. Aaron Liu (talk) 01:00, 1 March 2024 (UTC)[reply]
Got anything good? Tell us about your new, improved, old, or messed-up script here!
Making user scripts load faster by SD0001 is this month's featured script, which caches userscripts every day to eliminate the overhead caused by force-downloading the newest version of scripts every time you open a Wikipedia page. Despite being released in April 2021, our best script scouters have failed to locate it due to its omission from the US of L. For security reasons, the script only supports loading JavaScript pages.
Ahecht has created a fork of SiBr4/TemplateSearch, which adds the "TP:" shortcut for "Template:" in the search box, and updated it to be compatible with Vector 2022.
AquilaFasciata/goToTopFast is a much faster fork of the classic goToTop script that also adds compatibility for Minerva and Vector 2022.
Without caching. Each script takes 400–500ms. A particularly large script takes 1.11 s! Internet download speed is 50 Mbps.With caching enabled. Each script takes just 1-2 ms to load.
To a lesser extent, the same goes for PrimeHunter/Search sort. I wish someone would integrate the sorts into the sort menu instead of adding 11 portlet links.
Dragoniez/SuppressEnterInForm stops you from accidentally submitting anything due to pressing enter while in the smaller box, and works on almost anything... except the InputBox element itself, used in subscription lists and the Signpost Crossword! Oh, the humanity!
Doǵu/Adiutor(pictured) provides a nice, integrated interface to do some twinkley tasks such as copyvio detection, CSD tagging, and viewing the most recent diff.
Eejit43 has quite the aesthetically pleasing scripts, all made in TypeScript.
/afcrc-helper is a replacement for the unmaintained Enterprisey/AFCRHS and processes Redirects for Creation and Categories for Creation requests.
/ajax-undo stops the "undo" button from taking you to another page while providing a text box to provide a reason for the revert.
/redirect-helper(pictured) adds a much better interface for editing and redirects, including categorization, for which valid categories are dictated by /redirect-helper.json.
/rmtr-helper helps process technical requested moves without being able to actually move them.
Guycn2/UserInfoPopup(pictured) adds a flyout after the watchlist star on userspace pages that displays the common information you might use about a user.
Jeeputer/editCounter, under userspace, adds a portlet link to count your edits by namespace, put them in a table, and put that table in a hardcoded subpage, all in the background.
Hilst/Scripts/sectionLinks converts all section links to use the § sign, which are known to be preferred over the ugly # by 99% of the devils I've met.
PrimeHunter/Category source.js adds portlet links to tell you where a category for an article comes from and supports those from template transclusions.
Dragoniez/ToollinkTweaks adds more and customizable links next to users in page history, logs, watchlist, recent changes, etc.
Firefly/more-block-info optimizes the display of rangeblocks in contribution pages. Doesn't work outside the English locale of any wiki, unfortunately.
NguoiDungKhongDinhDanh/AjaxLoader makes paging links (e.g. older 50, 500, newest) load without refreshing and makes you realize how slow your internet actually is.
Ahecht/RedirectID adds the redirect target to all redirects. For all the WP:NAVPOPS haters. (Do these exist?)
Dragoniez/MarkBLockedGlobal: Remember the "strike blocked usernames" gadget? Now you can use a red, dotted line to highlight rangeblocks and global locks!
Jonesey/common(pictured) has some styles to overhaul your Vector 2022 experience. It reduces padding everywhere, and makes the top bar animation faster.
Aaron Liu/V22 is a fork that narrows the sidebars instead of upheaving them, reverts the January 2024 dropdown changes, and restores the old page-link color for links that don't go outside the current wiki.
Nardog: SmartDiff is a spiritual successor to Enterprisey/fancy-diffs. It makes the page title part of links in diffs clickable, along with template and parser function calls. Unnamed parameters can be configured per template to also be linked. All links are styled based on the normal CSS classes of rendered links.
For the paranoid: Rublov/anonymize replaces your username at the top of the screen with the generic "User page" text. Remember, it is your duty to persuade everyone that editing is an honor.
/AjaxBlock provides a dialog box for easy input of reasons while blocking users.
/Selective Rollback(pictured) provides a dialog box to customize rollback edit summaries and does them without reloading the page. Seriously, why doesn't MediaWiki already do this?
/flickrsearch adds a portlet link to search for uploadable flickr images about the subject.
/randomincategory adds a portlet link when on Category pages to go to a random page in the current category.
Vghfr/EasyTemplates adds a portlet link to automatically insert some of the most common inline {{fix}} templates.
Yes, we're just doing 'em as we go now. Thanks for reading through this looong issue, if you did! I'm sure this'll send a record for the longest issue ev-ah. You may need to wait even longer for the last issue, as our reserve of old-y and goodie scripts have ran out... We encourage you to try and do some of the requests or improvement tasks. See you in Summer, hopefully!
Dear Timeshifter, I have seen you answered a question about line break. I have a similar problem and need help. I'm from the german Wikipedia and less familiar with the english one. Now I caused trouble: I reworked this article: Digital Cleanup Day. It was written in a very confusing and promotional way, but to save at least something of the original authors work, I wanted to keep at least his great source work. The problem: Wikipedia does not allow line break between footnotes (for example after the word „France“ in this article) Can you force it to break the line? I hope, you can help or you know someone who can. All solutions are welcome, at worst reducing the footnotes, because right now it looks like sh**t. Thank you very much! Christian Thorwest (talk) 00:51, 5 March 2024 (UTC)[reply]
Hey there, welcome to the 25th issue of the Wikipedia Scripts++ Newsletter, covering all our favorite new and updated user scripts since 1 March 2024. We've got a ton of wonderful editors taking back their pitchforks today. Don't worry, for they come in peace, to forcibly fix and extend existing scripts you use with sheer passion. There's so many, them forks have got what's basically their own column now! gift us with some rows before it's too late Aaron Liu (talk) 04:01, 1 August 2024 (UTC)[reply]
Got anything good? Tell us about your new, improved, old, or messed-up script here!
To a lesser extent, the same goes for PrimeHunter/Search sort. I wish someone would integrate the sorts into the sort menu instead of adding 11 portlet links.
An easily configurable script to add a link to the #p-vector-user-menu-overflow portlet with a name, target, and icon. This one should be a relatively easier one. I would do it myself, but I'm too busy rotting away on Celeste (video game).
After the RIIJ update, Aaron Liu: Watchlyst Greybar Unsin has a dismiss button that allows you to mark an item as read in one click and cycle to the next Watchlist item.
Lordseriouspig/StatusChangerImproved is just like Enterprisey's script, except you select your status from a dropdown instead of cycling through them with a button. The WMF operates out of car-centric infrastructure anyway. Shame!
Aaron Liu has created Duplinks from Evad37/duplinks-alt; his fork adds a config variable to automatically highlight duplicate links on the loading of any page where the portlet link would've appeared.
Tired of staring at a bunch of filtering text and waiting for darn filter logs to load? Msz2001/AbuseFilter analyzer can parse abuse filters into a visual syntax tree and evaluate locally on-demand!
Polygnotus/DuplicateReferences finds references with the same link and displays the number of them along with a button to add the {{duplicated citations}} tag under the references section. Being lazy has never been easier!
fastest gun on the net Ponor/really-quick-block really quick add to contribution lists three buttons awesome
Users wishing to permanently leave may now request "vanishing" via Special:GlobalVanishRequest. Processed requests will result in the user being renamed, their recovery email being removed, and their account being globally locked.