Policy | Technical | Proposals | Idea lab | Miscellaneous |
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas. Before creating a new section, please note:
Before commenting, note:
|
« Older discussions, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 |
Centralized discussion | |||
---|---|---|---|
Proposals: policy | other | Discussions | Ideas |
For a listing of ongoing discussions, see the dashboard.
Note: entries for inactive discussions, closed or not, should be moved to the archive. |
|||
Contents
- 1 Self-destruction of 'Merge to' templates?
- 2 Wikipedia needs a "social icon" - and a safe place to land them
- 3 Replacement for the DYK process
- 4 Self edit conflicts
- 5 Include common abbreviations for cities/states/regions/countries etc.
- 6 Wanted: yellow links for articles that exist in Draft space
- 7 Advocate for more precise use of "date=" in fields of sources (-> to also have a field for "time=") & argue that Wikipedia should advocate for websites to use a international standard of reporting these, such that a bot can auto-report them + time-zone.
- 8 Maintenance collaboration
Self-destruction of 'Merge to' templates?
We have a considerable number of articles with 'merge to' templates that are now several years old (based upon the date listed in the template). These are cluttering up the lead without generating any activity. Could these be cleaned up after some period of time by a bot that migrates the suggestion to a section on the talk page? I.e. x months after the template is added, a bot looks for a matching "Discuss" section on the talk page. If it doesn't find one, then a boilerplate section is added listing the suggestion and the person who posted the template. The bot then removes the 'merge to' template from the article page. Praemonitus (talk) 19:04, 23 June 2016 (UTC)
- This suggestion has been made before, and generally the response is: "just because there's no discussion doesn't mean it's a bad suggested merge". If you think those pages shouldn't be merged, and there isn't discussion, just remove the tag. --Izno (talk) 19:12, 23 June 2016 (UTC)
- And if you think that it's a good idea to merge them, then merge them! Most of the old proposed merges are languishing for lack of someone willing to do the work of merging them. WhatamIdoing (talk) 21:33, 25 June 2016 (UTC)
- I don't believe that the opinion of one person regarding whether a merge should take place should take precedence over the style and usability of the article. If no merge has taken place, the talk page is a perfectly suitable location to put the suggestion. It should not be cluttering up the article lead indefinitely, detracting from the overall appearance and readability. There is, after all, no actual issue being expressed regarding the article content. Praemonitus (talk) 22:36, 28 June 2016 (UTC)
- Do you mean that the opinion of two editors (the editor making merge nomination plus the editor implementing it) is insufficient to make changes to articles? I don't believe that you'll get general agreement on that. WhatamIdoing (talk) 20:55, 1 July 2016 (UTC)
- A straw man argument? No that is not what I meant. If no other editor ever agrees with the opinion of the first, then the tag can still remain there indefinitely. There is no agreed upon mechanism for its removal. Praemonitus (talk) 22:03, 1 July 2016 (UTC)
- That wasn't a straw man argument; this isn't an argument of any kind, and he was asking a question about what you meant. I also thought the wording was slightly confusing. KSFTC 22:19, 1 July 2016 (UTC)
- "If no other editor ever agrees with the opinion of the first" is exactly what I'm talking about. You can be that "other editor". If you "agree[] with the opinion of the first", then we're talking about two editors who agree that the pages should be merged. In that case, we are not talking about "the opinion of one person regarding whether a merge should take place" (your comment at 22:36); we are talking about the opinions of two editors at that point.
If a merge has been proposed for "several years" (your first sentence), with nobody objecting enough to remove the tag or caring enough to comment on the talk page during all those years, then the agreement of the only two editors who cared enough to get involved (again: Editor #1, who proposed the merge, and Editor #2, who agreed with the proposal), then you shouldn't move the tag to the talk page and hope that a lively discussion about the merge will start. In that case, you should just boldly merge the pages. (Or boldly remove the tags entirely, if you disagree.) WhatamIdoing (talk) 00:32, 2 July 2016 (UTC)- If the merge has never occurred, then there is no editor #2 involved. All you've got are visitors who may or may not agree with the suggestion, but are distracted from their reading by the inert tag at the top of the page. Without a merge, it's only the opinion of the person posting the original tag that matters. On the other hand, if you don't care for the tag then boldly remove it without agreeing or disagreeing, you would seem to be in violation of WP:Civility. Praemonitus (talk) 21:08, 3 July 2016 (UTC)
- "If no other editor ever agrees with the opinion of the first" is exactly what I'm talking about. You can be that "other editor". If you "agree[] with the opinion of the first", then we're talking about two editors who agree that the pages should be merged. In that case, we are not talking about "the opinion of one person regarding whether a merge should take place" (your comment at 22:36); we are talking about the opinions of two editors at that point.
- That wasn't a straw man argument; this isn't an argument of any kind, and he was asking a question about what you meant. I also thought the wording was slightly confusing. KSFTC 22:19, 1 July 2016 (UTC)
- A straw man argument? No that is not what I meant. If no other editor ever agrees with the opinion of the first, then the tag can still remain there indefinitely. There is no agreed upon mechanism for its removal. Praemonitus (talk) 22:03, 1 July 2016 (UTC)
- Do you mean that the opinion of two editors (the editor making merge nomination plus the editor implementing it) is insufficient to make changes to articles? I don't believe that you'll get general agreement on that. WhatamIdoing (talk) 20:55, 1 July 2016 (UTC)
- I don't believe that the opinion of one person regarding whether a merge should take place should take precedence over the style and usability of the article. If no merge has taken place, the talk page is a perfectly suitable location to put the suggestion. It should not be cluttering up the article lead indefinitely, detracting from the overall appearance and readability. There is, after all, no actual issue being expressed regarding the article content. Praemonitus (talk) 22:36, 28 June 2016 (UTC)
- And if you think that it's a good idea to merge them, then merge them! Most of the old proposed merges are languishing for lack of someone willing to do the work of merging them. WhatamIdoing (talk) 21:33, 25 June 2016 (UTC)
I don't feel like we're managing to talk about the same thing. So here's a simple example:
- I (=one editor) propose a merge of Example and Related. It sits ignored for years.
- You (=one editor) eventually see the tag and believe that a merge is a good idea.
- Using normal counting numbers, do you and I constitute "one editor" or "two editors"?
WhatamIdoing (talk) 18:51, 7 July 2016 (UTC)
- Yes, definitely some talking past each other going on. I understood Praemonitus comments to mean:
- In that scenario, is the second editor justified in being WP:BOLD to remove the tag? Or for more cautious or gun-shy editors, is the alternative to simply tolerate the visual clutter? older ≠ wiser 19:10, 7 July 2016 (UTC)
- That question is answered in the last bullet point at WP:MERGECLOSE in the "General advice". WhatamIdoing (talk) 19:17, 7 July 2016 (UTC)
- That entire process is contingent on their being a discussion. What about the case of an editor performing step 2 only? Praemonitus (talk) 19:26, 7 July 2016 (UTC)
- No, it isn't: "If the proposal is obvious...then a discussion need not even be held." MERGE is not AFD. It's not supposed to be a bureaucratic process with checks and balances and careful consideration. It's basically a plain old edit, which any plain old editor can undo with the plain old WP:UNDO button.
- The last bullet point says "If there is a consensus against the merger, or, for older proposals, if there is no consensus or no discussion and you don't believe it is appropriate to merge the pages, then please remove the merge proposal tags, and, if necessary, close any discussion." For your convenience, I've highlighted the three words that you accidentally overlooked. WhatamIdoing (talk) 20:32, 7 July 2016 (UTC)
- Yes, it's well concealed in the last part of the last entry in the final box near the last section, and still doesn't address my concern. Ah well. Thanks. Praemonitus (talk) 14:57, 8 July 2016 (UTC)
- That entire process is contingent on their being a discussion. What about the case of an editor performing step 2 only? Praemonitus (talk) 19:26, 7 July 2016 (UTC)
- That question is answered in the last bullet point at WP:MERGECLOSE in the "General advice". WhatamIdoing (talk) 19:17, 7 July 2016 (UTC)
-
- Yes thanks, that's close to what I meant. What I was proposing is why can't that template then be migrated to the talk page as a boilerplate discussion? The reasoning being that the idle template clutter is doing more harm than good, but the concept can still be preserved on the talk page. Even if somebody then comes along later and adds a merge template back in, they will then have a discussion to reference and some history to view. Praemonitus (talk) 19:21, 7 July 2016 (UTC)
- If you think that the merge idea is a poor one, then it's much better to remove the tags entirely, rather than sticking them on any page. WhatamIdoing (talk) 20:29, 7 July 2016 (UTC)
- That's not what I'm saying either. I'm not expressing any particular opinion on the merge; to me it's just useless defacing of the article. Discussions of that nature belong on the talk page. Praemonitus (talk) 14:57, 8 July 2016 (UTC)
- If you think that the merge idea is a poor one, then it's much better to remove the tags entirely, rather than sticking them on any page. WhatamIdoing (talk) 20:29, 7 July 2016 (UTC)
- Yes thanks, that's close to what I meant. What I was proposing is why can't that template then be migrated to the talk page as a boilerplate discussion? The reasoning being that the idle template clutter is doing more harm than good, but the concept can still be preserved on the talk page. Even if somebody then comes along later and adds a merge template back in, they will then have a discussion to reference and some history to view. Praemonitus (talk) 19:21, 7 July 2016 (UTC)
- Writing as someone who has done a lot of merges, many merge tags generate no discussion, sometimes for years. In these cases, an editor needs to make an evaluative decision. Is the merge an inherantly good suggestion? If no, then remove the tag. If yes, then leave the tag, regardless of how long it's been on. Remember there is no deadline. You should also consider doing the merge yourself, if you find time. --NickPenguin(contribs) 16:42, 10 July 2016 (UTC)
Wikipedia needs a "social icon" - and a safe place to land them
I was reading a (Note, link not safe for some workplaces. Prominently features photo of topless woman. <- Note that is not my text, see below, but as long as we're at it, let's continue... -> Unlike an image of Muhammad, which a person would have to belong to some stupid wrong religion to object to, or the word "fuck" that you'd have to be silly to object to anywhere on wiki because it doesn't bother the Guy In Charge, a link to an activist organization with important things to say is just too pretty to be given without a big bold stupid warning. So says User:TenOfAllTrades, who takes personal responsibility for proclaiming a policy (that isn't a policy) that prohibits people from having anything in their comments that would astonish HIM, and only him, and exerts final editorial control over all our work here on Wikipedia as the official Self Appointed Censor of the Wiki. Note also that he has claimed that posting to a picture of male breasts is also "astonishing", so if you see any news links to shirtless guys, please forward them to him so that he can go after their posters threatening AN/I. Man typing stuff in bold in the middle of a post is stupid, isn't it? I should do it some more. ) typical news article that has a bunch of icons for its presence on Facebook, Instagram, Pinterest, Twitter, and YouTube ... not Wikipedia. And obviously there's a reason why, which is not just the lack of an icon. For a group to want to have an icon, they would have to land at a site for them, i.e. a site where they can build up a list of useful resources and direct their followers as they see fit. Now I understand that Wikipedia has had a standoffish policy toward "social media" functions, not unreasonably since there are a lot of worms in that particular can. Nonetheless, I think it would make sense for us to allow this one particular kind of social media function in order to draw readers into the site and provide people with a place where they can address wikipedia-specific issues - indeed, the standard format provided for such spaces could ask groups setting them up to answer questions that every Wikipedia editor wants to know, like whether all those lovely pictures are CC-BY or something. And so I think that not only could we draw in readers, but we could draw in content with it.
Now yes, most companies would want to abuse this space terribly. But they already want to abuse our articles. If we could see free to allow them latitude to use their social media space pretty much as they wish, at least this would give them a choice - do we want more data stuffed in an article that might get deleted or be subject to stupid rules against directory information, or can we put it on our Wikipedia social media page? So it might not draw as much COI to the encyclopedia as we think.
Now yes, we'd want this "wikipedia social media" to be far from the articles. Not so far that a Wikipedia login wouldn't work, but probably a separate domain name would be sensible. It's conceivable that some neglected but loosely defined project like Wikiversity might actually be open to it, though I think it would make more sense to start from scratch.
The landing sites I'm picturing should not be in any sense user pages, but much more closely resemble Wikiprojects. We have a rule against company accounts; our users are individuals. This has always been in part so that we don't have to settle which of two co-owners holds the right to the company account after they have a falling out. That said, nobody is going to build their pages with a Wikipedia icon that is equally under the control of haters of their organization. This is where the philosophy comes in - we want to create a neutral and respectful structure that gives no privilege to any one point of view, yet allows each point of view to claim its own space. This is the same core problem as say arranging for protests at a political convention, so it is a hard problem, but we can address it much better than those who don't try to do so honestly. My thinking is that we allow any user to start a social media landing site with a given core name, but we append a bit of random fluff to the end so there can be many different ones, each no more expected than the other. Going to the core name without the fluff gets a directory of all the possible extensions, ranked by incoming page requests (but discounting abusive traffic). They then link each other as they see fit.
Typical valid content for a social media landing site would be personal bios, company products, addresses, phone numbers, basically anything in WP:NOT, plus anything the less friendly editors would boot from the article, plus discussions of how to build Wikipedia pages and collaborate to get better content. Sometimes this would be unpleasant to see, but it will happen whether we see it or not, so if we lure some of it out into the open that is not a bad thing at all. We would want the site as free as achievable under current legal conditions, and as independent as achievable in case something goes wrong. Its administration would be independent of Wikipedia and (as much as possible) WMF, perhaps outsourced to whoever makes the stupid decisions social media providers make to cover their asses. Obviously I would prefer to just leave it free entirely, but I recognize that there are severe risks in a less than free society. To summarize: it should be "user content". One obvious practicality is that the total size is limited, though the number of subpages it is distributed among should not be. (Why shouldn't a Wikipedia icon link to a social media entry for a particular event?)
The cost could be substantial but could be compensated in multiple ways. One would be ads, since it's not Wikipedia. Another would be subscriptions, for people with no interest in the encyclopedia. Perhaps the coolest way would be to allow it as a privilege for long term users in good standing; as such it would be a sort of in-kind payment for editing. I would not even want to prohibit users entitled to have such pages from offering to set them up for companies in exchange for money - the usual paid editing restrictions shouldn't apply to this social-media otherworld. I think though that trying to make it revenue neutral would be a mistake, because the goal is to get a stream of users to pass through the sites into Wikipedia. So I'm thinking something very mild, like hitting users with ads (with strict privacy limitations!) only if they use the social media site without using WMF projects proper - no more than a chiding for them to edit, really. And of course visitors to those sites should get a harsher dose of WMF fundraising appeals than the usual reader. Wnt (talk) 14:12, 29 June 2016 (UTC)
WP:TPO bullet 4. OT about NSFW warnings. ―Mandruss ☎ 07:00, 19 July 2016 (UTC) |
---|
|
- I'm reading this as "we should set up a social media button to draw in readers and content", and "the button should lead to a separate site that tolerates spammy and/or POV behaviour". Not only do I not like the second part of that, but I think it's fundamentally incompatible with the first. If we set up a "social media site" where organizations can control their content, many of them will simply park their usual ads there and ignore us. Worse, we'd have to manage such a site, diverting volunteers, WMF staff, and effort from our real goals, with no guarantee that this would do anything to lessen the effect of spam on our existing articles (In fact, I'd wager the opposite…). That's a side-show I'd rather not attend.
- Social media buttons are advertisements for the "social" site they represent. They say, implicitly: "this social site is more important than the site you're currently on". Including them gives the host site a chance at a smidgen of extra traffic in exchange for giving the social site ongoing free advertising and, if hosted centrally, the opportunity to track users around the rest of the web (!). They're a remarkable con. Wikipedia is not a "social platform" in the same sense. Our purpose doesn't include "sharing" random external sites, and in fact for many sites "sharing" them on Wikipedia would be disruptive to us. I do think that a "cite this article" social button could be interesting for news, academic (journals etc.), and GLAM sites—that would promote more or less behaviour we like, while filling the usual "social media" tradeoff. The catch for us being that the "cite this on Wikipedia" button would probably quickly appear on press releases and random blogs. {{Nihiltres |talk |edits}} 15:33, 29 June 2016 (UTC)
Social media buttons exist to drive content to the social media site and to the site which is linked to by a kind of mutual linking. This is great for small blogs which might otherwise have trouble getting noticed, but Wikipedia is almost always in the first page of search engine hits, so we don't need it, and we have no reason to want to drive content to social media sites. We anyway get featured on Facebook as the default page on any topic which doesn't yet have a Facebook presence, and people link to Wikipedia articles on social media all the time without social media buttons. I therefore strongly oppose this proposal. --Slashme (talk) 06:34, 19 July 2016 (UTC)
- So, I'm reading a news story "Man bites Dog" on the Daily News website, and I see that it has a wikipedia icon on it. Where does clicking on that icon take me? The wiki page for "Man"?, the wiki page for "Dog"?, the wiki page for "Daily News"?, some completely new "Wikipedia social network" page? If it goes to some existing page, who decides which one? If you're proposing building a completely new social media site, why? There's not exactly a shortage of them. Chuntuk (talk) 14:05, 19 July 2016 (UTC)
-
- @Chuntuk: Since it's on the Daily News' page, it's their choice. My strong presumption is that they would lead people to a Daily News Wikipedia fanpage, where some of their people would presumably try to encourage readers to cite their articles on various relevant pages, while readers would talk about what CC-licensed photos are available, debate the publication's quality, etc. Now all of this would have an alarming propensity to be misused by commercial interests -- but Wikipedia has done nothing to crack down on WP:WikiProject Square Enix and its featuring of an article on the Main Page every six months like clockwork, so we already have the worst end result of that so far as I see, minus the social media button. The social media button is to bring in readers, and companies corralling their fans into the works might actually dilute the commercialism of the process. In any case, they would be at least bringing in individuals who ought to become more independent-minded editors over time. Wnt (talk) 17:18, 19 July 2016 (UTC)
Replacement for the DYK process
Based on the ongoing concerns and problems faced with the DYK project, I have drafted a proposal to replace DYK at User:SSTflyer/DYK replacement. My proposal is designed to use as much of DYK as possible. What are your thoughts on it? Would such a proposal be feasible? How could it be improved? SSTflyer 07:06, 8 July 2016 (UTC)
- @SSTflyer: An interesting idea. You listed "Solves accuracy and interest concerns about hooks" as one of the advantages of this proposal. Honestly though, I'm not sure how much this is going to solve. There will still inevitably be disputes about whether or not information is correct, because this is just like DYK, but instead of hooks needing to be cited, blurbs need to be cited. The other problem I see with this is that by implementing this you lose the interesting facts which are normally provided by the DYK section, and instead the information presented will most likely be a little boring, and not really eye-catching or to the point. Omni Flames (talk) 08:11, 8 July 2016 (UTC)
- Perhaps instead of replacing the "Did you know..." section, the recently created/expanded requirement from DYK could be dropped. This would free it up to cover a broader range of articles with interesting hooks, and your proposed "Recent additions" sections would cover new/expanded articles. isaacl (talk) 12:54, 8 July 2016 (UTC)
- A blurb format might be a little dull, as Omni Flames said, since it would basically be a short summary instead of a short, weird fact. Then again, a lot of DYK hooks seem boring to me because I don't pay attention to pop culture.
- I would second dropping the new/expanded/GA requirement as a way to improve DYK. I created a lot of articles before I ever attempted DYK, and then wished I could do DYK on those articles when it was too late. I also often come across neat facts while editing other articles. White Arabian Filly Neigh 22:02, 11 July 2016 (UTC)
- I don't think the recency-requirement thing is a bad thing, but I think the window of opportunity is far too brief. I've often thought of DYKing some of my work only to discover that I was already outside of that overly tight window. It's hard enough doing the hard work of creating/expanding/GAing, and to have to immediately turn around and file a DYK is exhausting. Additionally, there is a group of editors who file so many DYKs they almost have a lockdown on it. Expanding the window of opportunity would encourage a lot of editors who haven't tried it before. Softlavender (talk) 18:42, 14 July 2016 (UTC)
Self edit conflicts
Include common abbreviations for cities/states/regions/countries etc.
Most cities/states/regions/countries have a 2- or 3-letter abbreviation. For example, the city of Phoenix, Arizona is abbreviated "PHX". It's useful information that non-residents might not know. It should be listed in the article for Phoenix. Similarly, common 2- or 3-letter abbreviations should be listed where applicable. — Preceding unsigned comment added by 174.79.47.243 (talk) 19:21, 12 July 2016 (UTC)
- I don't think I fully understand this. Abbreviations for countries and US states are shown in the infoboxes of their articles (though, as an aside, I think it'd be good to show ISO 3166-1 alpha-3 country codes as well as two-letter codes). But city abbreviations? NYC, certainly; but is PHX really used as an abbreviation for the city of Phoenix, Arizona? It's the IATA code for Phoenix Sky Harbor International Airport. Many IATA codes for US airports indicate the names of the cities they serve, but not all, and they're still airport codes, not city codes. — Stanning (talk) 07:23, 13 July 2016 (UTC)
- It probably is used, at least by people who travel a lot or like airplanes. There are some older abbreviation systems that were in general use (e.g., initials for any city that had more than one word, an X to replace "Cross" in any city whose name begins with Cross). There are also official abbreviations for some places. CalTrans has assigned an abbreviation to every county and some other places in California, for example. WhatamIdoing (talk) 01:44, 14 July 2016 (UTC)
- They appear to have spread beyond the flying context for some cities, especially in URLs, hashtags, and the like, where an abbreviation is wanted (and presumably for places with only one international airport). I’ve certainly seen usage of YEG (not always in caps) around here in recent years by organizations & campaigns with no obvious connection to travel or tourism. I‘d expect the codes to appear somewhere in the Transportation section of major-city articles, but I‘m not sure they generally deserve any more prominence unless they‘re actually (citably) used as nicknames. WT:WikiProject Cities, or maybe Template talk:Infobox settlement, might be a better place to bring this up.—Odysseus1479 05:29, 14 July 2016 (UTC)
- PDX for Portland, Oregon also. --Izno (talk) 11:40, 14 July 2016 (UTC)
- Sounds very locally specific. I can't see why this would be useful for cities- what does the code LGW or LHR add to London? The TLA for railway stations is used in texting, as in 'At CST, all cancelled will walk top STP' but the codes are already in the station infobox. Still irrelevant to a settlement article. --ClemRutter (talk) 18:44, 14 July 2016 (UTC)
- PDX for Portland, Oregon also. --Izno (talk) 11:40, 14 July 2016 (UTC)
- They appear to have spread beyond the flying context for some cities, especially in URLs, hashtags, and the like, where an abbreviation is wanted (and presumably for places with only one international airport). I’ve certainly seen usage of YEG (not always in caps) around here in recent years by organizations & campaigns with no obvious connection to travel or tourism. I‘d expect the codes to appear somewhere in the Transportation section of major-city articles, but I‘m not sure they generally deserve any more prominence unless they‘re actually (citably) used as nicknames. WT:WikiProject Cities, or maybe Template talk:Infobox settlement, might be a better place to bring this up.—Odysseus1479 05:29, 14 July 2016 (UTC)
- It probably is used, at least by people who travel a lot or like airplanes. There are some older abbreviation systems that were in general use (e.g., initials for any city that had more than one word, an X to replace "Cross" in any city whose name begins with Cross). There are also official abbreviations for some places. CalTrans has assigned an abbreviation to every county and some other places in California, for example. WhatamIdoing (talk) 01:44, 14 July 2016 (UTC)
There are common city abbreviations used for sports teams. Perhaps a "List of abbreviations of sports teams in North America"? --NaBUru38 (talk) 15:11, 17 July 2016 (UTC)
Wanted: yellow links for articles that exist in Draft space
This may not be for everyone, but it seems like it would be productive to have links like Selwyn Wright (presently a red link which I just saw mentioned at the Science Refdesk as an article that 'might be started') show up as yellow rather than red if Draft:Selwyn Wright exists. That way, if for example you are looking at a genus page with fifty different species listed, you would immediately see the one yellow link among that sea of red and say great, let's see if we can get that article whipped into shape! This might not be for everyone, needing a user setting and hence only being available to editors rather than casual readers, depending on how freaked out people get by the alleged horrors that someone will write libelous things about Mr. Wright in Draft space - I'd prefer to have it for everyone and just ignore this risk as nothing much to get bothered over, but I remember there were people dead-set against Draft space, and the compromise would not really be a terrible bar when accounts are had for free. I imagine this could be done in user javascript using some API feature to check for existence of Draft:anything in the page, but that would be a terrible waste of resources if many people used it, compared to having a varnished version sitting on the server you don't need a script for. How would people feel about it? Wnt (talk) 16:42, 14 July 2016 (UTC)
- I've never seen yellow type show up well anywhere. What about green? Or instead of font color, some other indication? Softlavender (talk) 16:51, 14 July 2016 (UTC)
- This should work as a user script that adds a CSS class, similar to Anomie's linkclassifier. SiBr4 (talk) 17:59, 14 July 2016 (UTC)
- Hmmm, it does look like it would fit in there; I wasn't familiar with that script. But I don't understand how that script can access all that information without putting a huge performance hit on both the user and the server. Wnt (talk) 02:42, 15 July 2016 (UTC)
- Nearly all the rules look at nothing but the names of the categories the page is in; the exceptions are needs-review, nonimage, redirect and its children, and the protection-related. עוד מישהו Od Mishehu 04:00, 15 July 2016 (UTC)
- I added code to have it check mainspace links for a corresponding Draft-namespace page, and set the
has-draft
class on them. I didn't add any default CSS rule for this, though, largely because I couldn't think of what styling to use. Anyone using the script can, of course, add a rule for.has-draft
(or.new.has-draft
if they only want to target redlinks) to their personal CSS. Anomie⚔ 19:22, 18 July 2016 (UTC)
- I added code to have it check mainspace links for a corresponding Draft-namespace page, and set the
- Nearly all the rules look at nothing but the names of the categories the page is in; the exceptions are needs-review, nonimage, redirect and its children, and the protection-related. עוד מישהו Od Mishehu 04:00, 15 July 2016 (UTC)
- Hmmm, it does look like it would fit in there; I wasn't familiar with that script. But I don't understand how that script can access all that information without putting a huge performance hit on both the user and the server. Wnt (talk) 02:42, 15 July 2016 (UTC)
- The color of the link could be orange or something else - I didn't think yellow looked all that bad, but orange would work. I assume it would be as easy to check if Draft:X is in a category as X? Wnt (talk) 11:51, 18 July 2016 (UTC)
Advocate for more precise use of "date=" in fields of sources (-> to also have a field for "time=") & argue that Wikipedia should advocate for websites to use a international standard of reporting these, such that a bot can auto-report them + time-zone.
- According to Wikipedia:Citing sources, User:Citation bot "automatically fixes common errors in individual citations and adds missing fields". The page of that Citation bot states:
"Searches for missing parameters (including URL), then adds them if available. This is especially convenient when only an identifier is included within the template
- The bot uses a range of databases including Google Books API, PubMed, CrossRef, AdsAbs and the JSTOR API"
- "date=" is one parameter/field of a cited source. I don't know whether bots (such as the cited Citation bot) can automatically add or verify the "date=" field in a source, whether it is missing or not (specifically, I'm talking about cite web references and cite news references? But if it can not, I would argue it would obviously be very handy if a bot could crawl for dates in all cited on-line resources, and add the dates automatically.
- These days, a more and more precisely measured and reported world, should allow wikipedia to crawl for the "date=" more accurately. I am talking about the problem here which currently arises when users manually enter the "date=" of different sources, due to sources using different time zones. I argue that even a field such as "time=" would be of importance (this would record the exact time, up to hours and minutes and seconds, according to how specific the information is recorded by the news source). Analogue, "access-time=" could supplement "access-date=".
- As for "date=" and "time=", I think it would be handy if there would be an on-line automatically communicating international standard established; which can be used between on-line sources. That would enable sources to "upload" this standard to their servers (where they thus can specify the exact date and time, as well as their time-zone). One can argue that there already exists such "date", "time", and "time zone designator" formats to be included as meta-information into the HTML of websites. Wikipedia could advocate for websites to use this more heavily, for example by creating a list of websites which factually use a certain standard. On those sites, Wikipedia bots could crawl automatically for this information (according to the international standard; or standards; which it has learned to crawl), and adds this information as "parameters/fields" of cited resources.
- It would be nice, if according to the time-zone which the Wikipedia viewer chooses, all of the instances of "date=" and "time=" are automatically changed and updated to be viewed according to her/his time-zone. — Preceding unsigned comment added by Verheyen Vincent (talk • contribs) 15:56, 21 July 2016 (UTC)
Maintenance collaboration
In 2005, Maurreen started the Wikipedia:Maintenance collaboration of the week which later became inactive. I've been trying to revive it. Recently, I came upon the Backlog of the Week, which is apparently updated automatically by AnomieBOT. This would make the MCW somewhat redundant. Would it be feasible for the MCW to use the Backlog of the Week for their collaboration? Is anything like this already in existence, and would anyone be interested? Chickadee46 (talk|contribs) (WP:MCW) 17:33, 21 July 2016 (UTC)