This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Personal attacks and incivility in non-English languages should be treated equally
In this page, there is no mention or section about personal attacks in African, Asian, European languages. Often users don't get blocked for making non-English personal attacks or BLP violation. Administrators should not ignore such language and word, if the victim gives source where the actual meaning of the word is given. Making personal attacks in other languages using English alphabets is gaming the system. In the Wikipedia policy page of "No personal attacks", it must be written that those who make personal attacks in other languages should also be blocked, if the comments are too gross, violent or offensive. --182.66.56.52 (talk) 07:27, 19 May 2016 (UTC)
If a victim reports a personal attack in a non-English language, whether or not a source is supplied where the actual meaning of the word is given, then I don't understand how such an addition to the policy would make any difference. I cannot imagine any admin who would ignore such an attack just because it was made in another language as long as the attack is reported. Can you show any examples where personal-attack reports in a non-English language have been ignored while personal-attack reports in English that are of the same or later date have been handled? Stick to sources!Paine08:00, 19 May 2016 (UTC)
Actually the page says "Do not make personal attacks anywhere in Wikipedia".Point. It doesn't say that the attack has to be in English. An admin will act if it is reported; if he is capable of understanding the language, he will act without it being reported. So I concur with Paine Ellsworth: examples, please? Lectonar (talk) 08:29, 19 May 2016 (UTC)
There are many many examples where users survived after making dirty comments in other languages. I remember a few.
When Indian users face personal attack in Hindi, Urdu, Bengali, Tamil, Telugu, Punjabi languages, they have to tolerate. 182.66.56.132 (talk) 09:15, 19 May 2016 (UTC)
Please keep 2 things in mind: Firstly, some admins may have tools to help them find specific words which are usually disruptive; these words would, almost certainly, be in English. Secondly, most admins wouldn't recognize bad words in any given language other than English. I, personally, would recognize Hebrew cases (for example, I blocked a user called Ata tipesh, which means "You are stupid" - it was a soft block because I had no evidence that this was actually a Hebrew-speaking user); I would not recognize issues in Hindi, Urdu, Bengali, Tamil, Telugu, Punjabi, or even French. And I'm not sure that I would necessarily take someone's word on the meaning - if anything, I would try to catch the attention of an admin who does speak the language. עוד מישהוOd Mishehu19:50, 19 May 2016 (UTC)
There seems to be nothing to fix here. The policy is in no way limited to attacks in English. The only "problem" here is that people often cannot read/recognize attacks in foreign languages. That is not something that can be fixed by re-writing policy. Attacks can only be dealt with if they are reported. I expect admins will typically treat reported foreign attacks equally, and in most cases the attack can verified by typing it into an online translator.
If there is evidence of a pattern of cases where admins knowingly disregard foreign attacks then I would support adding a (redundant) sentence to policy stating that it applies regardless of language. Alsee (talk) 22:25, 19 May 2016 (UTC)
Even machine-translation has its problems:
It only works in the language's actual alphabet, not transliterated; so while it could work for French, it would not work for Urdu text written in the Latin alphabet.
There are probably languages which any given translater can't handle.
For short texts, you probably need to have a human being identify the language.
The same word may have multiple meanings, where a machine may be incapable of knowing which meaning is intended. For example, is a specific use of the word "cock" referring to a male bird, or to a likely attack? I'm sure other languages have similar issues.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I declined it via AFC as unreferenced, and as needing wikiheadings and wikilinks. I am reasonable sure that the subject is notable, but reliable sources are needed to prove notability. Robert McClenon (talk) 01:59, 12 May 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
pdf option button has .tex button to download the source .tex (latex probably)
Making a pdf from a viewed article is a good idea but the practical results for heavy math articles is poor, so that PDF is often not usable. IF you would offer an option to download the
underlying .tex file, then those of us who are very familiar with tex - Latex, could hack it into a very nice document. Just add a button alongside the to PDF
that might read to Underlying .tex file.
Just and idea. — Preceding unsigned comment added by LarryHickey (talk • contribs) 22:06, 19 May 2016
i am not aware that there is such a thing as "the underlying .tex file". in fact, i can say with confidence there is none. true, math (and other) articles may contain some latex markup, but the page as a whole is not set up in latex, and i'm not familiar with any tool that can create one. if you know of such a tool, then you can propose to utilize it, otherwise this proposal is not actionable. peace - קיפודנחש (aka kipod) (talk) 23:20, 19 May 2016 (UTC)
I know the original article is not from latex source, but when I click the (make me a pdf) button off to the left side, wiki goes off and thinks for a moment and returns with a .pdf I can download. That thing, used to make me a special pdf from the published article, surely must be .tex or latex source? even if the original article is not? If you say it's not- then maybe you could release the markup stuff that created the .pdf and a tool to convert that markup to a .pdf
. (like pdflatex converts the latex source to a pdf.)
I don't want to put anything back to wiki, just to hack it to make it suitable for my uses, so long formulas look ok etc. — Preceding unsigned comment added by LarryHickey (talk • contribs) 00:53, 20 May 2016
Non-AFC drafts in draftspace have no G13 method for automatic deletion. Or for any review at all. As such, there are hundreds of stale drafts that haven't been edited in a long time. Attempts to add G13 or other criteria have been repeatedly and expressly rejected so instead these pages take up a lot of time at WP:MFD where deletion is somewhat routine. Limiting an idea lab suggestion, I'd like to propose that we allow for a new draft proposed deletion system with the following rules:
Draftspace drafts that are not tagged with AFC that haven't been edited in six months can be considered.
If the deletion is proposed, it would go into a dated category similar to Category:Proposed deletion for at least one month at which time any one can remove the proposal for any reason whatsoever. This is similar to the 5 month notification of Category:AfC G13 eligible soon submissions with a month before G13.
After a month with no deletion, an admin can then decide if it's worth deleting.
I also tag draft with WikiProject so I imagine we can have WP:ALERTS for these draft prods similar to Prods so projects can see if there's anything of interest. Any thoughts? It's much lengthier than an MFD discussion but it's also essentially a single veto and not a consensus. Deletion can still be done at MFD if the prod fails and it still hasn't been improved. -- Ricky81682 (talk) 20:15, 5 May 2016 (UTC)
Didn't we discuss a similar proposal quite recently? I support something like this, and would prefer G13 to be abolished to be replaced with this draft prod. — Martin (MSGJ · talk) 20:43, 5 May 2016 (UTC)
Oppose. There is no reason to delete good drafts just because people want to drive users away from the site. — Preceding unsigned comment added by 166.171.121.222 (talk) 21:02, 5 May 2016 (UTC) Strike banned user — JJMC89 (T·C) 02:15, 6 May 2016 (UTC)
While we get a lot of G13 requests at WP:REFUND a good 20% or so of them are re-requests for a draft that has seen multiple G13s. Of these, about 60% of them don't get restored because the person requesting re-restoration won't answer the followup question for requests of that nature. ("If we were to undelete this again, what efforts would you take to make it an acceptable article?") —Jeremyv^_^vBori!21:31, 5 May 2016 (UTC)
I support such a proposal as well. Common sense needs to prevail, and this can easily be controlled on a case-by-case basis, all the while removing unnecessary bureaucratic stops. Best, FoCuScontribs; talk to me!16:27, 19 May 2016 (UTC)
Currently, we have a lot of problems with people removing legitimate deletion notices. I propose a bot that would reinstate these notices, if the illegitimate removal is automatically detectable. It should do the following:
Reinsert any speedy deletion notice if removed by the article author
Reinsert any XfD notice if the discussion is not closed
Reinsert BLP PROD notices if the only change to the article after insertion of the notice is the of removal of said notice
Optionally, the bot could also reinsert PROD notices if the removal has been manually reverted before
I think this would solve many problems with deletion notices; this bot would especially help with persistent vandals who edit in bad faith and have some knowledge on how Wikipedia works. --Laber□T18:32, 16 May 2016 (UTC)
There already is a bot that does some of this, can't remember which one. Regarding "reinsert PROD notices if the removal has been manually reverted before" - this needs to be done very carefully, since in general, a {{proposed deletion/dated}}, once removed, may not be re-added whatever the reason for its removal, see WP:DEPROD. --Redrose64 (talk) 20:21, 16 May 2016 (UTC)
Yes, since PRODs can be restored only under very limited circumstances, I doubt the process can be automated. This proposal should focus on speedy and XfD tags only. – Finnusertop (talk ⋅ contribs) 20:29, 16 May 2016 (UTC)
Support first 2, oppose last. A manual revert may be no more than an otherwise VOA user removed it, someone blindly restored it, and later an anonymous user chose to contest the deletion. Unsure about BLP PROD. עוד מישהוOd Mishehu09:37, 17 May 2016 (UTC)
Support first 2. SDPatrolBot, operated by Kingpin13 used to replace CSD tags but it hasn't operated in over 2 years; I'm not sure if there is another bot currently doing this. The third one I'm not sure about, what if the BLP PROD is removed because it was added erroneously? It would be better if it could detect and revert the removal from an article that is unsourced but you would need to be careful because some new editors will just add external links or unformatted plain text as a reference. I oppose the last one. As replacing PRODs is only done in a few specific circumstances, I think that would need to be manually assessed. Sarahj2107 (talk) 12:24, 17 May 2016 (UTC)
Oppose, speedy deletion tag removals are easily found using the edit filter and can be looked at by hand. A page creator removing an obviously frivolous CSD tag is fine, reverting that by bot is not. I think we have a bot that re-adds AFD templates after a while, which is OK. However, TFDs are often removed when they ought to be noincluded, and reverting the removal is probably not the best course of action. —Kusma (t·c) 13:43, 17 May 2016 (UTC)
If you;'re worried about noincludes, the bot could be written so that it if it restores an XfD tag on a page with transclusions, it adds it in noinclude tags. עוד מישהוOd Mishehu18:17, 17 May 2016 (UTC)
Having administrator rights for CheckUser is necessary because of the ability to block users only lies with administrators, but I don't see any reason why non-admins can't be oversighters. — Music1201talk03:51, 25 May 2016 (UTC)
All of the rights necessary for suppressing naughty content are included in the oversight group. To the best of my knowledge, there is no policy requirement for an oversighter to also be an administrator. In practice, users who are trusted with OS rights tend to already be administrators. Ajraddatz (talk) 04:18, 25 May 2016 (UTC)
The WMF requires users who will have access to deleted revisions to undergo an RfA or RfA-like process. Presently, the only way to gain oversight access on the English Wikipedia is to be elected to the arbitration committee or to be appointed by the arbitration committee. Because the appointments are not considered to be an RfA-like process, that leaves a non-admin with only the former option. Mike V • Talk04:52, 25 May 2016 (UTC)
All due respect to the former Director of Community Advocacy, but I'm not sure how true that is.
m:Oversight policy#Access specifies that on wikis with an Arbitration Community (and which does not prefer local elections), that "users may also be appointed by the Arbitration Committee" with no reference to an RfA-like process. The only requirement is that ArbCom be elected with over 25 supporting votes, which enwiki clearly meets.
Given that temporary adminship may be granted on any Wikimedia wiki after a public notice and week of discussion (an RfA-like process), I fail to see how the WP:CUOS system would not qualify as that, if it is even required. Yes, ArbCom makes the appointments, but there is a chance for community input in a way that meets the basic standard for granting adminship.
I've been a steward for over two years now, but had not heard of this RfA requirement until I became active here on enwiki again. It isn't in any of our policies or guidelines. I'm not sure if it's an old requirement, if it was meant to only apply to enwiki, or if it was never more than a "best practice" decided by the WMF. Either way, stewards assign access to CU/OS rights based on actual codified policy, so a non-admin could become an oversighter without being a local admin on the request of ArbCom. Ajraddatz (talk) 05:06, 25 May 2016 (UTC)
Ajraddatz, here, it was stated by WMF that in order for a user to be granted access to deleted revisions, they must have been through "an RFA or RFA-identical process". That was in 2013, not sure how things would've changed since then. Omni Flameslet's talk about it05:21, 25 May 2016 (UTC)
I'm not sure either, but that is not a policy requirement for gaining CU/OS rights (or even admin rights). And even if it was a requirement, a very compelling argument could be made that WP:CUOS fills that requirement when compared to similar processes which grant access to deleted revisions or non-public info. Stewards assign CU/OS rights based on actual, written policy. But like I said above, I wonder if it was intended to be enwiki-only or something else. Ajraddatz (talk) 05:34, 25 May 2016 (UTC)
Since those comments predate the current nonpublic information policy, it's probably worth getting clarification from the WMF on whether this 2013 statement still applies. Opabinia regalis (talk) 23:37, 25 May 2016 (UTC)
@Ajraddatz: If you dig around in my stewardwiki pages, there may be some more on that, but that is an "unofficial" WMF requirement. It seems to only have been enforced on enwiki, though. --Rschen775400:35, 26 May 2016 (UTC)
Thanks Rschen7754, I found some on it. As Opabinia regalis mentioned, it's probably worth asking the WMF again, and if it does get them to write it into one of the relevant policies. Ajraddatz (talk) 04:09, 26 May 2016 (UTC)
Is the request for a new process, a Request for Oversight, or for some other way of doing this? There's no reason we can't create a separate process for oversight access that's separate from admin rights. However, why is this necessary? What process is one that could use more oversighters that doesn't require administrators? -- Ricky81682 (talk) 06:43, 25 May 2016 (UTC)
Indeed; is there a backlog at oversight? Do emails to the oversight team go unanswered for half a day (or more)? Has there been a request from the oversighters that they need more team members? Has there been a reduction in the number of oversighters?
To my last question: I don't think so, there are presently fifty oversighters, a substantial increase on the figure of 35 in January 2012 (rising to 41 about three years ago). The last removal of the oversight right was at 18:12, 7 May 2016, being a self request from Beeblebrox (talk·contribs), and the last granting of the oversight right was to Floquenbeam (talk·contribs) at 19:03, 31 January 2016.
What I was saying above is that being an admin is not a policy requirement for being an oversighter, according to the global policy. Therefore, the only block is locally on enwiki due to some strange opinion given by WMF staff years ago, which seems to apply only to arbcom appointments here, if that. Ajraddatz (talk) 21:32, 25 May 2016 (UTC)
Last year, ArbCom sent out a questionnaire to people who were interested in the oversight role. Essentially this was to make sure the candidate understood the role and what it involved, and we could understand why they wanted it and whether they were suitable. Two of the questions were "(If applicable) When did you pass Requests for Adminship:" and "(If an administrator) Please list all situations where anyone has disagreed with your use of revision deletion and provide your comments". Which suggests that non-admins would be considered for the role, although everyone who applied last year was already an admin as I recall. I'm not on this year's committee so cannot say what current plans are or if they have changed. Thryduulf (talk) 22:36, 25 May 2016 (UTC)
Oversight is enhanced deletion. A significant aspect of the oversighter's role is to determine when deletion revision (or straight deletion of a page) is sufficient to serve the purpose without actual suppression. So what is really being proposed is whether or not to give deletion tools to a non-administrator; the oversight tool is supplemental to deletion tools. As such, I'm not really very supportive of this notion; the enwiki community has established a very high (in my opinion, excessively high) standard that they expect admin candidates to reach before they get the deletion tools. Enwiki has 51 oversighters, which is almost as many as the rest of the Wikimedia projects altogether. There have been extended periods (including recent times) where oversighters have been nearly tripping over each other to be first to respond to OTRS oversight requests. We're hardly in desperate straits here. Risker (talk) 04:32, 26 May 2016 (UTC)
I just looked at the numberedlist at m:Oversight, which said there were 51. Perhaps someone should fix it - for some reason I can't edit the page there. Risker (talk) 16:28, 26 May 2016 (UTC)
When looking at that list the first thing I noticed was that Alison is listed, who I mentioned above as having given up the right yesterday; I then looked a little further down and spotted another name that I mentioned above, i.e. Beeblebrox; so it's not been kept up to date. Checking more carefully, I find that the list also includes Seraphimblade, who lost the bit at 23:32, 1 January 2016. That reduces it from 51 to 48 - the discrepancy between that and my 49 is that Jimbo Wales is not listed, although he does have the oversighter right. --Redrose64 (talk) 17:32, 26 May 2016 (UTC)
That page draws from m:Oversight policy/Requests for oversight, which apparently needs to be marked for translation every time it is edited in order to update the "en" version that is displayed. The only way to edit the list is to go to that page and change it. What a nightmare... Fixed now. Ajraddatz (talk) 18:45, 26 May 2016 (UTC)
I don't want to start big dicussions as this might be already discussed but just to ask why is Wayback Machine more used than Archive.is?
I got much better experience with Archive.is, for example. It is much faster + it has much more pages archived than Wayback + it has much shorter URLs when compared to Wayback (and generally too). --Obsuser (talk) 00:35, 1 June 2016 (UTC)
The issue is that archive.is (previously archive.today) has used bots to try to inject their archive links into WP, bringing the site's true purpose into question (see the first RFC to blacklist archive.is links). The Wayback Machine/archive.org has very explicit goals and show respect for things like Robots.txt (even if this makes archiving some places a PITA). Note that for single page archiving we do support WebCite, again whose intentions and purpose are clear. --MASEM (t) 01:06, 1 June 2016 (UTC)
Personally I have more confidence in the Internet Archive (Wayback) being in the preservation of digital heritage business for the long term in good faith, in contrast to the one guy behind archive.is who seems to be acting on a whim with unclear motivations. – Finnusertop (talk ⋅ contribs) 01:26, 1 June 2016 (UTC)
Archive.is pros: archives any page without respecting robots.txt (because of this effective opt-out allowance, archive.org won't archive certain domains, and existing archives can be removed if the domain owner implements robots.txt later).
Archive.is cons: unlike archive.org, it has an opaque funding model, says it might run ads, hasn't been around all that long, harder to be confident it'll be around some years from now, and people (allegedly connected to the site) have repeatedly spammed wikipedia with links.
Aside: The URL is shorter because it has a built-in link shortener. Like if you took an archive.org link and sent it through bit.ly (link shorteners are typically blacklisted too). — Rhododendritestalk \\ 02:34, 1 June 2016 (UTC)
May I point out that so far archive.is is a nightmare for bots. The header information is apparently not preserved, making it hard for the bot to determine if the archive works or not. The shortened URLs don't help either, especially since Cyberbot II, running InternetArchiveBot, always needs to save the original URL, and sometimes need to resolve it from the archive URL. To sum up, the likelihood of getting a false positive when querying archive.is for an archive is significantly greater, than it is for archive.org.—cyberpowerChat:Limited Access03:25, 1 June 2016 (UTC)
OK, thank you. I did assume this outcome because Wayback is way professional and looks like that (that might be reason for slow functioning). However, there are indeed more pages and robot.txt archived ones on Archive.is so it is useful.
I've even assumed that Archive.is was or was meant to be blacklistted domain on Wikipedia because it is kind of a pirate or something... Is it recommended or is it safe/good to add Archive.is URL if Wayback doesn't have a particular web page archived? I guess it is not, especially if Wayback cannot display/archive it because or robot.txt and Archive.is has it beautifully archived.
But shouldn't it be allowed for everyone to take a snapshot of any web page as I can do that right now and save it somewhere? It was public in one moment; that means someone could take a snapshot in that moment, remember what was displayed etc.--Obsuser (talk) 03:38, 1 June 2016 (UTC)
That's why I mentioned WebCite [1] which is a good way to save a single page like this. It serves the same function as archive.is but, like Archive.org, we know what their purpose and reason is. --MASEM (t) 04:58, 1 June 2016 (UTC)
Might as well also plug an idea I threw out at the RfC that didn't get a whole lot of traction :) (it is sort of a tangent): Regardless of whether or not archive.is is removed from the blacklist, I think it would be useful to add parameters to Template:Cite web to allow for more than one archive. I think best practice is to use archive.org whenever possible, but we could also have a webcite archive (or archive.is if it's taken off the blacklist, or something else that comes along) just in case. Link rot is, to me, a much more significant problem in the long-term of Wikipedia than saving a few characters in a citation. I don't know the best way to implement that. At bare minimum the second archive wouldn't even have to be displayed in the reflist, or could just be a linked word like "backup" or "webcite"... — Rhododendritestalk \\ 15:43, 1 June 2016 (UTC)
Update WikiProject participant lists based on activity
The "Participants" lists in WikiProject space often don't distinguish active users and inactive users. This makes it hard to find active users, especially when there are only a few of them in a long list of inactive users. I propose that a bot go through all the participant lists (or whatever subset we can get a consensus for, such as only those projects that have opted in) and move inactive users to an "Inactive participants" section in each list. There are a lot of different ways this can happen; for instance, if the bot detects that a majority of the participants are inactive, it can make an "Active participants" section instead. At the moment, I think a good definition of activity is "at least one edit in the past three months".
What do you think? Should this be implemented? Should it be opt-in or opt-out? I personally think making it opt-out diminishes its utility, given that the only thing the bot is doing is changing the order that project participants are listed and adding a section heading, but of course I'll defer to a consensus otherwise.
Yes, I've seen it, but I don't think it exactly addresses this specific problem (for instance, the WP:WPX lists aren't self-selected, but the WikiProject-space lists are). However, I think, say, links to the directory from the participant pages would be helpful. Enterprisey (talk!) (formerly APerson)17:25, 1 June 2016 (UTC)
Unblock Requests Transparency
Currently there exists a log of all blocks, which can be examined. The fact that it exists and can be examined is crucially important to transparency. There exists no such log of unblock requests which links to them/lists whether or not they were granted. Therefore, there is no practical manner by which to get a big picture sense of what is going on in the realm of unblock requests; there is simply no big picture transparency. I'm concerned (may or may not be true but there's no way to know) that there is a relatively small numbers of block happy admins dealing in this realm, thereby chasing away potential editors and thereby harming Wikipedia (which appears to be having a major problem recruiting/retaining new editors). I propose a log be implemented (how this would be implemented technically would have to be determined later on).68.48.241.158 (talk) 13:36, 30 May 2016 (UTC)
these are interesting links..not sure I've seen them before, thank you. I don't think they solve the general transparency issue I've described..as the first link appears to only show those that were granted as opposed to those that were denied??...and the other is quite unpractical and therefore not very transparent at all...like to see a straightforward log of all unblock requests that links to them and lists whether they were granted or denied..68.48.241.158 (talk) 14:50, 30 May 2016 (UTC)
I don't know that the process can get general transparency: there are requests made to WP:UTRS that should not be open for public scrutiny, especially if personal information is revealed in the process. —C.Fred (talk) 15:02, 30 May 2016 (UTC)
this appears true but we could at least get transparency as far as the traditional and likely most often used unblock requests (ie don't let perfect be enemy of the good or whatever)..68.48.241.158 (talk) 15:25, 30 May 2016 (UTC)
I would strongly object...this is an actual proposal...I never proposed anything over there but sought general info about how tech changes are implemented..68.48.241.158 (talk) 15:28, 30 May 2016 (UTC)
What I mean is that it could be combined here or there, be sure to at least link to each page. It could also get its own page somewhere if it will take a long time to develop (then link the centralized page from these pages). — xaosfluxTalk16:18, 30 May 2016 (UTC)
the linking you did is fine but think combining clutters as that thread is a lot of technical discussion not related directly to the particular proposal..68.48.241.158 (talk) 16:53, 30 May 2016 (UTC)
Indeed. Not sure if they expect a different answer by posting in a different place. They have already been given all they need to find this info, it will just take a bit of effort. HighInBC15:05, 30 May 2016 (UTC)
you're not understanding things once again, HighBC...that other thread was asking about how technical things are implemented if they are found desirable...I never proposed anything there but sought and received general info...I've now proposed something..68.48.241.158 (talk) 15:21, 30 May 2016 (UTC)
"I propose a log be implemented" - to be clear - are you proposing that a process be implemented for this, the English Wikipedia, to require some sort of logging for these actions? (Putting aside the mechanics of "how" it will be implemented)? — xaosfluxTalk16:21, 30 May 2016 (UTC)
I don't understand the question..I don't know if anything is "required" per sey...but if it was thought to be a good idea and then implemented it would then exist (I notice above there is something called "phabricator")..68.48.241.158 (talk) 16:40, 30 May 2016 (UTC)
We are all volunteers here. We can't come to a consensus in a proposal that somebody write this tool. If someone is willing to write it they can do so but we can't decide as a group that somebody should do it. You have expressed your desire for this tool in both places so really they are redundant. We try to keep discussion in one place by merging topics that have been cross posted. HighInBC16:44, 30 May 2016 (UTC)
Let's define the problem better. Are you wanting a log of unblock requests or of declined unblocks? —C.Fred (talk) 16:53, 30 May 2016 (UTC)
I envision something like this: a log wherein every time a traditional unblock request is made on a talkpage an entry is created...it will also have a column showing whether it's open/granted/denied..and will memorialize all of them overtime down the list...pretty straightforward..68.48.241.158 (talk) 16:57, 30 May 2016 (UTC)
So, we'd need a bot looking for any user talk page that has an unblock template added, and then it would have to determine whether the request were still open, declined, or granted. How would it deal with frivolous or invalid unblock requests, where the unblock template was properly deleted? —C.Fred (talk) 17:00, 30 May 2016 (UTC)
(edit conflict)Logs can take many forms, they can be software generated, or they can be manual (e.g. Wikipedia_talk:IP_block_exemption/log). Manual logs can be enforced via administrative controls (i.e. policies) - where as software logs are primarily automated. For software you basically have 2 options: someone (even you!) could run a bot to examine edits and record findings - or the backend could be changed via extensions or patches. Any software logs would required that their input parameters are met, which would also require policies if this is to cover a 99% use rate (e.g. unblock request must be made via this mechanism, administrators and editors are to ignore other inputs, such as email requests). — xaosfluxTalk17:03, 30 May 2016 (UTC)
the technical issues would have to be dealt with by any eventual/potential coders...my sense would be it's fairly trivial coding by today's standards..I don't follow most of what you state..but that's really a different discussion anyway..68.48.241.158 (talk) 17:07, 30 May 2016 (UTC)
Xaosflux brings up a very valid point on the behaviour front. If the logging system requires use of the {{unblock}} template, are requests that don't use it to be ignored, or should admins apply the template before servicing the request? Or will the logging system be savvy enough to recognize a declined/granted unblock that was never logged while open?
If you're proposing that all unblock requests be manually logged, then I oppose that on the grounds of rules creep and potential for more abuse. If all declined unblocks have to be manually logged, a lot of admins will get short fuses when it comes to users who repeatedly request to be unblocked, and more blocked users will get talk-page access revoked. —C.Fred (talk) 17:11, 30 May 2016 (UTC)
What percentage of unblock requests would you want this proposed process to capture? Are you only trying to monitor the use of {{unblock}}, or any way someone can ask to be unblocked (e.g. a UTRS ticket, a talk page message, a request without using a template)? — xaosfluxTalk17:13, 30 May 2016 (UTC)
sure, require insertion of the template if the coding would require it..what's the big deal? and it would all be automated once coded so don't understand this manual stuff..but rather focus this discussion on the proposal and whether it's a good idea in itself instead of speculating about tech issues (which we may not be qualified to)..68.48.241.158 (talk) 17:16, 30 May 2016 (UTC)
I strongly oppose anything that would limit editors attempting to appeal a block to only one specific mechanism. I support any bot ideas to produce a report of unblock requests/results/notes. — xaosfluxTalk17:19, 30 May 2016 (UTC)
I guess you are looking for something similar to the log at WP:SPI. I think you are looking for a continuous log not one that lists the ones open. -- GBfan00:23, 31 May 2016 (UTC)
It would be fairly easy to log {{Unblock}} , on the understanding that other requests would remain unlogged. this would be subject to gaming of course. All the best: RichFarmbrough, 11:05, 31 May 2016 (UTC).
what are you talking about 'fairly easy to game'??? it would just log things..whether people were 'gaming' things in any sense (I have no idea in what sense this is referring) could then be seen.68.48.241.158 (talk) 11:29, 31 May 2016 (UTC)
So, what's the motivation for this proposal? In my experience, most declined unblock requests I come across have been legitimate. I don't really see why this is being proposed. Why do we even need such a log - I'm not aware of any unblock declining epidemic going on here... Sergecross73msg me12:34, 31 May 2016 (UTC)
see the OP for the motivation; it's clearly explained. 'in my experience'..that's the problem...I'm after transparency; not interested in relying on your experience..68.48.241.158 (talk) 12:50, 31 May 2016 (UTC)
Okay, if that's the extent of your explanation, and this is all about you being sour that your unblock requests being rejected, then I oppose based on the lack of need of said proposal. Sergecross73msg me13:02, 31 May 2016 (UTC)
your input is unsubstantive, assumes bad-faith, and as an admin is totally inappropriate. It will therefore be discounted. Indeed, my proposal is designed to create more transparency on the activity of admins, who I am concerned about..and obviously your behavior does nothing to alleviate that concern..good day..68.48.241.158 (talk) 13:12, 31 May 2016 (UTC)
My response is not inappropriate - I asked you for more reasons as to why we conceptually need this, and you gave me a lazy "Eh, go look it up" response. Was that really supposed to convince me? Or anybody? If you don't want assumptions about your motivations, then try explaining yourself better. I'm not alone here, most participants seem either confused on what you actually want, or have concerns about feasibility or loopholes. Have you not noticed the majority of your discussions end up fizzling out in this same way? Sergecross73msg me13:39, 31 May 2016 (UTC)
The problem with creating a log of unblock requests on Wikipedia is that there will be big holes in the log. There have been about (from what I can figure out) 16000 unblock requests made through WP:UTRS. For approximately a month now the requests have had some on-Wiki information posted but not most of the information that is being discussed being included in the log. It is just basic information that a request has been made and then that it has been closed. It contains no detailed information about the request. Another hole is the unblock requests made by email to admins, those will never be logged anywhere. -- GBfan13:27, 31 May 2016 (UTC)
that's okay, no reason to let the perfect be the enemy of the good...a log of standard template unblock requests on public talk pages (which I'm sure is the vast majority of unblock requests) will be a huge increase in transparency..68.48.241.158 (talk) 13:30, 31 May 2016 (UTC)
NOTE: I'm operating under the assumption it's a good idea to get/demonstrate support for the proposal before bringing it to/looking into who might be willing to code it/implement it....but perhaps logs/bots/apps of public Wikipedia data are simply allowable to be made regardless of anyone else's support of it.....???68.48.241.158 (talk) 13:56, 31 May 2016 (UTC)
Not sure if it was mentioned above (haven't checked all the diffs) but open unblock requests are already logged here CAT:RFU. It probably wouldn't be a huge stretch to have a category, CAT:URFU (unsuccessful Requests for unblock?), that looks for the denied flag in a closed unblock request, although I would leave it with the coders to come up with a system that handles multiple unblock requests on a page. Blackmane (talk) 14:23, 31 May 2016 (UTC)
yeah, I'd imagine it wouldn't be too difficult to code...and multiple requests would be fine; I would want them to be included...they'd just be another entry on the list..68.48.241.158 (talk) 15:56, 31 May 2016 (UTC)
A FINAL NOTE: (I think).....after learning more about the process of how bots are created/introduced, I'm not sure this thread was ever particularly needed...it seems it's more a matter of me simply making a bot request, seeing if anyone is willing to make the bot, and then seeing if the bot is approved...obviously there's no possible harm from my proposal but only potential benefit in creating a bit more transparency...so it's kind of a pointless discussion here..68.48.241.158 (talk) 18:40, 31 May 2016 (UTC)
In line with the draftspace proposed deletion, I note that there are tens of thousands of old drafts in userspace from the Article Wizard days (those go back to 2009 but there's another five thousand or so going back to 2004 and that's only those using those templates). The consensus from this RFC was that drafts that "which will never meet GNG" can be deleted per WP:WEBHOST. Rather than regular and repeated arguing at MFD, I'd like to propose that we allow for a new userspace draft proposed deletion system with the following rules:
A userspace draft where: (a) the user has not edited for five years; (b) where the draft (absent bots) has not been edited in five years AND (c) where any editor in good-faith believes that the draft "will never meet WP:GNG" can be proposed for deletion.
If the deletion is proposed, the talk page for the creator and the userspace it is (if they are different) will be notified that the draft has gone into a dated category similar to Category:Proposed deletion for a minimum of six months during which time anyone can remove the proposal deletion for any reason whatsoever.
After this six month window with no one removing the proposed deletion, an admin can then review it and if the admin also believes that the page will never meet WP:GNG, the page can be deleted after this five and a half year window of inactivity.
Once a proposed deletion has been removed, it cannot be relisted for proposed deletion for another five years. It can always be taken to WP:MFD at any time of course or if it fails a CSD criteria but this is a once-in-a-half-decade situation.
Now, I'm not suggesting five years of inactivity to make fun or to make some WP:POINT given the other discussions. WP:STALE currently uses a one-year standard but repeated discussions at WP:MFDregularly (and I mean regularly) contend that editors who have not been active for three/four, even seven/eight/nine or even ten years should not have their content deleted for fear of driving them away from returning. The most extreme examples are the ten year drafts but five years seems to be about a fifty-fifty line about where the MFD "regulars" dispute that level of inactivity to me. Note that none of these disputes are not about whether the draft is actually viable content, that's another matter, just whether the deletion of a page somewhat agreed upon as junk should be done at all. Further note that even with how absurd five years after the person's last edit sounds, five years back as a starting point leads us to May 2011 and covers approximately 17k old Article Wizard drafts or roughly half of that backlog which could be somewhat resolved in six months without taking up any space at WP:MFD. Any comments? -- Ricky81682 (talk) 09:17, 22 May 2016 (UTC)
I hope this isn't an unwelcome tangent, and Ricky81682 you'd know better than I whether this has already been hashed out elsewhere, but it seems like some of the headaches around this could be mitigated (though, admittedly, not eliminated) through tweaks to the messages/mechanisms we provide the users whose drafts are deleted. If it said something like "as you have not edited in more than 12 months and this draft has not been edited in more than 12 months, it has been removed as part of routine cleanup. If at any point in the future you return and would like to restore this draft (or if any other user would like it restored), click the button below and an administrator will restore it just as it was before." [big button that says "restore my articletitle draft"]
My language isn't very carefully thought out, but the idea is to eschew all the standard, some say unpleasant looking, deletion messages -- and even the word "deletion" -- from the message, making it clear "we've moved it to a box in the basement for now because you haven't been by the house lately, but let us know and we'll put it back in your bedroom". I can't imagine that would put many people off.
In other words, I like the idea of proposed deletion because it has an inbuilt mechanism for easy restoration of the article. Even though technically it's still deletion, if what we're worried about is driving people [to stay] away, framing and the assurance it can easily be recovered seems like it would help. — Rhododendritestalk \\ 13:02, 22 May 2016 (UTC)
This makes sense; the long post-tagging pre-deletion window gives plenty of time for objections. We need to send a message that makes it absolutely clear that this is merely a cleanup process, rather than some sort of "you were bad"; I can't think of anything better than what Rhododendrites has written. Nyttend (talk) 13:54, 22 May 2016 (UTC)
Agreed, the language should entirely different. More like "hey, we haven't seen you in a while" (a while being five years here) but if you do come back, come to WP:REFUND or bug an admin and it'll be restored." -- Ricky81682 (talk) 20:00, 22 May 2016 (UTC)
I am guessing, because it still shows up in title based searches and thus still acts as a distraction to people who are hunting for problem pages or salvageable ones.Jo-Jo Eumerus (talk, contributions) 15:11, 22 May 2016 (UTC)
I doubt it's anything so practical. I suspect that it's just a personal preference for deletion – the greater feeling of the page being completely "resolved", for example. WhatamIdoing (talk) 20:07, 22 May 2016 (UTC)
Blanking only involves the blanker and the creator and is one-time solution. This allows for old drafts to be seen by more people, categorized if they want, organized if they want and reviewed if people have an inclination. If someone else thinks it's worth working on, they can do it. Otherwise, the only I'd find something if I did a search and checked in userspace. Now, I guess you could argue that we should blank it after this five-and-a-half year window but I'd say after that much time, we may as well delete it and move on. Also, some people take a very strong preference in being the creator of a page (one of the reasons I propose to delete draftspace versions regularly) and I've seen arguments come up over history-merging in old pages by people who kind of domain-name squatted stubs into the mainspace version that someone else actively worked to then take credit later. Given those feelings, I don't see what's wrong with encouraging the people here now over treating the person who did something a half decade ago with such reverence. -- Ricky81682 (talk) 20:19, 22 May 2016 (UTC)
Blanking is way better and serves the same purpose, so there we go. Since drafts do nothing and rarely get attention, I see 0 reason why we'd need to mitigate its scrutiny but a "few" editors can't just leave them alone and I can do no better than suggest a compromise. --QEDK (T☕C)17:04, 22 May 2016 (UTC)
In other discussions, people thought that having your drafts unilaterally blanked without notice and without any place for discussion is more likely to drive away editors than at least some notice and instructions so they can comment and figure out what happened. I have no issue if people propose blanking during an MFD discussion because the creator at least as some idea what's going on. -- Ricky81682 (talk) 20:00, 22 May 2016 (UTC)
Since you're talking about people who already haven't edited for five years, I think that we can ignore the "maybe someday they'll login again" thing. Accounts with <1,000 edits and an absence of some months almost never return. WhatamIdoing (talk) 20:07, 22 May 2016 (UTC)
A few pages like these are actively watched. They may not log in but if you blank or nominate it for deletion, they do come out of the woodwork. If blanked, it won't be clear if it's been unblanked unless it's watched (which is very minor anyways). -- Ricky81682 (talk) 20:14, 22 May 2016 (UTC)
And if it's un-blanked – a rare occurrence for such old drafts – then it'd no longer be eligible for deletion under your proposal, so in that case, it shouldn't have been deleted. The more I think about this, the more I like the idea of PROD with its normal standards for uncontroversial deletion of hopeless pages, and just blanking for the rest. WhatamIdoing (talk) 01:38, 23 May 2016 (UTC)
I'd prefer that we not bother with PROD (which requires an admin's time) and instead use the quick, simple, lighter weight option of replacing the contents with a template that includes instructions on how to immediately un-blank the page. And I wouldn't necessarily object to a bot doing this, although a bot generating a list, allowing any interested editor (if any exist) to quickly review the contents of each page, and then deleting any that weren't removed from the list, might be preferable. WhatamIdoing (talk) 20:07, 22 May 2016 (UTC)
On the other hand, the goal I'm actually shooting for is more of a six month Category:AfC G13 eligible soon submissions for people to browse through if they want. That's sort of how the AFD notices evolved and how the Article Rescue Squadron started with the Prods. If it's blanked, it's blanked with no one other than the blanker and the creator knowing what happened. As someone who regularly goes through the AFC G13 cats, I've noticed that there's a severe lack of review for non-AFC pages and think we'd be better served with at least some system of review. If you find something started five years ago that's worth working on, we'll all better off. -- Ricky81682 (talk) 20:14, 22 May 2016 (UTC)
I support the general idea, give or take a few months/years on the deadlines. We must have some process to remove old pages, we do not know how long WP will last, maybe a few years, maybe a century, until the sun bursts, or beyond; but anyway, we should have processes to avoid increasing "to infinity" and this is a good one, it seems. (and there should be one to move unused usernamess aside eventually, I hope someone will take over user:nabla in the next century, while whatever is kept from me becomes user:nabla(2004-2051) :-) No joke, really.) - Nabla (talk) 20:28, 22 May 2016 (UTC) PS: I mean support the deletion, blanking solves little to nothing - Nabla (talk) 20:32, 22 May 2016 (UTC)
Oppose. It is too close to an unreviewed auto-deletion mechanism without sufficiently clear criteria. "will never meet WP:GNG" is hopelessly subjective, and flies in the face of the recent very clear RfCs that meeting the GNG is not required in userspace (or draftspace). If the criteria were "A draft that fails any point of WP:NOT", it would be much more palatable. I note that the frequent examples of terrible drafts are better described at WP:NOT violating (a policy), not WP:GNG violating (a very nuanced and contentious guideline). "Notability" and "GNG" should not be used in cleaning out drafts, the many sections of WP:NOT are more than sufficient. --SmokeyJoe (talk) 22:53, 22 May 2016 (UTC)
Agree with WhatamIdoing, that these proposals are administrator-heavy. It basically requires an administrator action, indeed it implies an implausible administrator review, of every unworthy draft. It is implausible to think that any of the few administrators can do this task at length without weariness leading to harsh judgement. UserSpace drafts should not be a source of administrative overload. Forget the PROD/deletion aspect of it, and replace bad drafts with a explanatory template. --SmokeyJoe (talk) 22:57, 22 May 2016 (UTC)
I'm not sure how this is unreviewed. We have a bare standard in mainspace and it's worked functionally for years. If it's not feasible then a backlog will occur and we can just close this down. It wouldn't be the first backlog we have. -- Ricky81682 (talk) 04:52, 24 May 2016 (UTC)
While it is true that there a people who review articles in Category:Proposed_deletion, the main review process justifying PROD is the assumption that there are interested page watchers. The more important the page, the more incoming wikilinks it has, the more editors who have noticed it, the more watchers it would have. And it was justified by the importance of keeping mainspace clean. These things are not true of draft space or userspace. Extending PROD to unwatched pages is to a create a new defacto CSD criterion, and as a new CSD criterion, it fails horrendously the new CSD criterion criteria.
I believe that when PROD was introduced, most pages had multiple watchers, and most editors were active editors. It is so very not true any more. How do you know it works functionally? Do you decide that on the fact that PROD deletions are occurring? I think it is a very loose assumption. --SmokeyJoe (talk) 05:20, 24 May 2016 (UTC)
I'd say the activity at WP:AFC shows there exists interested people who will review these pages. I mean, we discuss these regularly at MFD. And prod is also done constantly as part of WP:NPP. I doubt there's a lot of pages just created that are watched. If I wanted watched pages, then I would suggest than five years of inactivity before looking at these pages. I'm suggesting it precisely because they aren't watched. If there's something of interest, I'd just work on it myself and move it to mainspace. It's the ones that aren't that are question. We can continue to use MFD and have repeated arguments about them, perhaps blank them or just ignore them and let the tracking categories just grow into infinite. -- Ricky81682 (talk) 05:29, 24 May 2016 (UTC)
You could stop looking at the tracking category. It is a long way short of infinite. You still haven't articulated how this is good for the project, particularly the deletion of pages that don't violate WP:NOT. --SmokeyJoe (talk) 10:03, 24 May 2016 (UTC)
Strongest possible oppose This is insufficient time, editors can and do many multi year breaks and this just create a mass of excess work for no good reason. 107.72.98.9 (talk)
Support Lets not mix things up, if someone hasn't edited a draft in 5 years, zero edits to it, it is safe to delete. Dennis Brown - 2¢21:02, 26 May 2016 (UTC)
I'm not even going for that. If they haven't, they (or someone else) have another six months and it can be deleted. -- Ricky81682 (talk) 21:25, 26 May 2016 (UTC)
Oppose I legitimately do not care about userspace drafts and have yet to be convinced, despite reading pages of arguments for why we need it, that we need a deletion process for them. If it fits some sort of speedy criteria already, tag it and move on, otherwise why do we care? We have 6,908,426 articles, I doubt a few thousand stale drafts are really going to be a problem for the hardware. It's not like AfC draft space which has a reviewing process that needs some organization. Further, it just seems like another mediocre process that will wind up underused and backlogged and require another RfC to put it out of its misery. I just don't see this as necessary or beneficial. Wugapodes[thɔk][kantʃɻɪbz]19:12, 2 June 2016 (UTC)
Category:Userspace drafts created via the Article Wizard is a maintenance category and was used as a maintenance category for review in the same way that Category:Draft AfC submissions is a maintenance category. Pages were reviewed, either mainspaced or deleted through MFD and the tracking categories deleted for years (Category:Userspace drafts created via the Article Wizard from January 2009 was deleted in 2012). The problem is, unlike AFC, there was no G13 option so pages that sat there for years still sit there for years and you can't keep watch when there's literally 2-3k pages being created a month so people quit trying to weed though the mountain of junk. The issue is, we do review and remove pages currently under AFC. We just never cleared out the old junk because the volume of absolute crap is immense. There was over 48k pages there and over 15k were cleared out just by adding a CSD criteria for "the person literally didn't add a single character beyond the old article wizard and it's over a year old". Another half could easily be removed if it was changed to "the person added a single sentence without a source" and that same criteria but rather than trying to wiggle CSD criteria, I'm trying for a more sensible wholesale approach. Otherwise these are still going to be deleted at MFD where it will be the same "why are you deleting these? who cares if we've done it since 2008 without anyone caring? No, I'm going to oppose this because the person who edited nine years ago coudl return out of principle" rather than at least looking at whether there's an ounce of sense in keeping around 1000 pages of pure useless junk that has bots monitoring non-free images, people adjusting templates and other tens of thousands of worthless edits because you personally don't care if other people have half a decade year old junk to weed through again and again and then quit doing that. Again, if we had thought of G13 in 2009 instead of 2013, we'd have nothing here to talk about. -- Ricky81682 (talk) 01:12, 3 June 2016 (UTC)
Oppose per Wugapodes. Aside from the hardware space which gets cheaper and cheaper every year, as I see it admins have plenty of backlogs to choose from and get to work with. The level of admins must rise significantly (pretty unlikely) to allow clearing out all of those backlogs and this new one as well. Those backlogs actually seems to improve the front-end reader experience in ways huge to small - this process doesn't and simply takes up time that could be used elsewhere. -NottNott|talk Notify me with {{re}} 19:28, 2 June 2016 (UTC)
These are still being listed at MFD anyways. Unless your argument is to oppose the deletion at all, and there's been no arguments for why that would be other than "I think it's stupid and I've decided you should be volunteer to do something else", it's just creating new subpages at MFD and more work for admins that way. Believe me, I create and close them. Again, if G13 was started in 2008 and not 2013, we'd have nothing to talk about. These pages would have been CSD'd years ago and no one would be arguing about editor retention or space or hardware concerns, they'd just say "no one is going to volunteer to do a AFC review if you tell them you literally cannot delete a page that is absolute junk no matter how long it has been there and we don't care if we end up with 1000 pages of junk for you to weed through to find even one remotely usable thing." It's about the editors. I don't understand how no one is seriously suggesting that we eliminate G13 and not delete six month old drafts of no worth today but suggest deleting a draft of no worth from five years old and people raise holy hell. -- Ricky81682 (talk) 01:19, 3 June 2016 (UTC)
This discussion apparently was started 4 days after that one was closed as opposed... - jc3710:59, 31 May 2016 (UTC)
To be fair, that was a proposal to expand the current prod into userspace and would allow for any deletion. This one requires at least five years of inactivity and rather than one month, you have six months of review. -- Ricky81682 (talk) 18:48, 2 June 2016 (UTC)
RFC: Replace all instances of [h] in TeX/LaTeX (and in MathJax) with [tcb]
In MathML with SVG and PNG fallback we got the problem in phab:T136688 and phab:T136685. This mode is entabled by default because of phab:T131177. Currently this causes phab:T136688, phab:T136685, phab:T136672 and phab:T136709. While other workarounds are yet to be found the solution to phab:T136688 and phab:T136685 it will probably be solved by repacing all instances of [h] in TeX/LaTeX (and in MathJax) with [tcb] as [h] is not a valid tag and was seen by the PNG rendering mode as [tcb] but now causes an error in the new mode. I propose that some sort of bot or AWB script is written to automaticaly or semi-automaticaly replace [h] in TeX/LaTeX (and in MathJax) with [tcb] to fix this problem as this was already accepted as the correct solution (pending actual code workarounds) at phab:T136685#2345546.
For those of you who don't understand what I said above it was decided (phab:T136685#2345546) that a small edit-a-thon is necessary to replace [h] with [tcb] in some cases. This RFC is to decide whether or not to do that. Hungryce (talk) 02:59, 2 June 2016 (UTC)
Support Although I don't think it's really much of an issue. I checked my dump of all maths expressions from the en wikis in 2014 and there are 11 instances of using arrays with an optional parameter and none with the [h] parameter. Spin angular momentum of light had \begin{array}[l] and i've fixed that one. --Salix alba (talk): 06:14, 2 June 2016 (UTC)
Support Note, that \begin{array}[h] needs to be replaced by \begin{array} (\[[tcb]\] is a regular expression, denoting that valid arguments can be either t -> top, or b-> bottom, or c-> center. --Physikerwelt (talk) 16:09, 2 June 2016 (UTC)
@Physikerwelt: are you saying that it needs to be replaced by [tcb] or one of [t], [c] or [b]? If so can we just not have a tag as it appears that [h] and [l] does nothing. — Preceding unsigned comment added by Hungryce (talk • contribs) 16:21, 2 June 2016 (UTC)
How Should We Make The Edits? (RFC: Replace all instances of ...)
Discussion (RFC: Replace all instances of ...)
What? First, I am only getting 404 errors for all of those links in the prose. The links on the side work though, but I still don't understand how Phabricator works or what I'm supposed to opine on. For those of us without extensive knowledge of phabricator and TeX, could someone explain what this all means? Wugapodes[thɔk][kantʃɻɪbz]02:52, 2 June 2016 (UTC)
Thanks Hungryce for the clarification above. But with all good answers, it leads to more questions. I'm leaning supportmoved to support above but still need a bit more info. Is this a context sensitive change? Is this a cosmetic issue or content? I ask because of the bot policy and the answers affect whether a dedicated bot or an AWB script would be most beneficial/useful/within policy. Wugapodes[thɔk][kantʃɻɪbz]16:35, 2 June 2016 (UTC)
I am thinking AWB script because it is possible that the h is not used in an equation but a bot might think it is. I don't think that would be too big a problem as it is very spicific where the h is. I guess the issue is cosmetic because while it won't change how the equation looks to those useing PNG mode it would look like the error here rather than an equation for people using MathML with SVG or PNG fallback (the new default and recomended option). Hungryce (talk) 17:57, 2 June 2016 (UTC)
I too don’t understand what you wrote, and am not going to read all the phabricator links to see if there’s an answer at one of them. So can you provide one link for the 'it was decided' bit, even if just one of the links already provided?--JohnBlackburnewordsdeeds16:34, 2 June 2016 (UTC)
Hungryce, what is the question? Could you please summarize? what? why? what will improve? are any downsizes? instead of pointing to a bunch of links without any description (why would anyone want to read a page described as "phab:T136685#2345546"? Why not read also "phab:T123456#7890", "phab:T1#22", or "phab:T333#4444"...? - Nabla (talk) 12:50, 4 June 2016 (UTC)
@Nabla: I tryed to put a summary at the end if you don't want to read the phabricator bits as that is not nessisary. The question is do you support creating a bot or AWB script to replace [h] with [c] in the context of math equations. This is nessisary because [h] is not a valid argument for a math equation but used to be ignored and [c] was used by default. With the new default math rendering system it is not ignored and causes red errors for readers and they can't see the equation its self. You can see an example of one of these errors here. There are know knowen downsides enless the wrong thing is replaced but that likely won't happen. Hungryce (talk) 13:33, 4 June 2016 (UTC)
(fixed your link, above) User:Hungryce . Your summary says that "In MathML [...] is necessary to replace [h] with [tcb] in some cases". Should the average wikipedia editor know what that mean? I write the occasional TeX formula and had no ideia of what you were talking about. If I get anything from your explanation, it is that there is a parameter used in writing (MathML? TeX?) equations that used to be ignored but currently causes an error, making those equation impossible to render? So we need to replace that parameter "in some cases"? Which cases? How many of those exist? It is not the same replacing some 10 occurrences of something (which seem to be the case, reading some comments above) or to replace 10 million of them. If the case is to replace a few of them. please go and replace them, fine by me, equations should obviously be rendered. - Nabla (talk) 14:02, 4 June 2016 (UTC)
@Nabla: We currently don't know how many there are, there may be none, but just incase it would be good to go around and fix them. Hungryce (talk) 17:19, 4 June 2016 (UTC)
Why not write a bot that scans for any potential problems? Just getting the list ought not require any serious approval issues, unlike a bot that actually makes changes. And if it returns a few false positives, so be it. We're talking a bot that does a RegEx on each page? That should be trivial. If that returns a modest number of (potential) problems, we'll just fix them by hand. If there are thousands, a bot to do that would make sense. From Salix alba (talk·contribs)'s post, it seems likely to be a small number. Rwessel (talk) 05:53, 5 June 2016 (UTC)
It is more or less trivial. A scan on the December 2015 dump (it is the one I already had on my computer, ready to use) gives me a count of 629 pages with \begin{array}. Those include 4 templates, 1 help page, 2 drafts, and 622 articles (and a few on the wikipedia namespace, all of them archives, so probably better not care about them). Of those only 7 articles had one (or more) of \begin{array} [b] (1), [c] (3), [l] (1), [t] (2). The one with the [l] was the one already mentioned above. Full list:
Thanks @Nabla: The reason I have not made a regenx bot to find any uses is because I don't know how to do that so I want an RFC to back up my request for someone to make one. I will go and fix the ones that you found. It is likely those are the only ones but I still want to do an up to date search just in case.
I do not see the point of running a bot to check if maybe, just maybe, there is one wrong formula, but likely not. A wiki will unavoidably have a couple of erros, eventually someone will spot and fix it. Oh well, whatever, I will not oppose either. One thing my search above shows is that there were not a single help page explaining how to use, or not to use, these parameters, that would be a improvement I'd welcome, to avoid editors using it in the future. - Nabla (talk) 21:05, 5 June 2016 (UTC)
RfC: Unbundle the 'delete' userright from the administrator toolset
Closing per WP:SNOW. The community's consensus is clearly against this. Specifically, allowing users to take an action that they don't have the ability to undo is a problem that has not been resolved satisfactorily in this RFC. If this proposal were further refined at the idea lab, it might be better received, but for now I am not hopeful. Tazerdadog (talk) 05:34, 6 June 2016 (UTC) (Non-admin closer)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
A common problem I come across while new page patrolling is tagging pages with CSD tags. It's a problem because they can take hours to be deleted. There are so many users who have very lengthy CSD logs with mostly red-links, and the encyclopedia would benefit greatly by allowing editors other than administrators to delete pages. The deletion log is likely the lengthiest log, because hundreds of pages are deleted daily. It's strange that such a common process can only be done by sysops. I'm proposing that these rights be added to the proposed 'deleter' user-group: delete, undelete and deleterevision. The deletion of articles would also be restricted to pages created in the last 24 hours and with less than a certain number of edits (I propose 15). — Music1201talk03:53, 31 May 2016 (UTC)
Oh goodness. I don't usually comment on RfCs without a good number of prior comments, but this seems like a misguidedly premature proposal. 'delete' is a central component of sysop – perhaps even the defining component, see m:IRC/wikipedia-en-admins (defining 'admin' to be anyone with the technical ability to delete/protect pages). I would assume that undeletion would also be packaged in, which would require an RfA or RfA-like process to be allowed. This should have garnered discussion, perhaps at WP:VPI, to flesh out details before a full RfC was opened. Nonetheless, this oppose is to the whole proposal, which I think is unworkable on the merits however it could possibly be restructured. Kevin (aka L235·t·c) 04:13, 31 May 2016 (UTC)
Oppose The two key concerns at any RFA are whether the person should have the bit due to their sense in deleting content that should be deleted (or not deleting content that should not) and blocking. This doesn't concern blocking but I don't see way of separating the tools such that you aren't going to end with a RFA-like system to give the rights to the delete taskers. Besides, as noted, CSD has no backlog in comparison to things like CSD or other backlogs where being an admin isn't even necessary. -- Ricky81682 (talk) 05:09, 31 May 2016 (UTC)
Oppose deletion along with blocking is one of the two most contentious tools that an admin has. Plenty of RFAs have failed because the candidate's deletion tagging indicated that they would be heavy handed with the deletion button. Unbundling works where there is a right that we could give to a group of people who would use that right but are unlikely to pass RFA. There are or have been a lot of newpage patrollers doing sloppy work, damaging the pedia by driving away newbies with incorrect deletion tags. We should not make it easier for those who would misuse the deletion button to get hold of the deletion button. ϢereSpielChequers08:42, 31 May 2016 (UTC)
Oppose CSD isn't backlogged by much. (Admittedly it used to be only a few minutes backlog.) Moreover it is good to have two people check speedies, as WSC says not all CSDs are good candidates. All the best: RichFarmbrough, 10:46, 31 May 2016 (UTC).
Oppose as unworkable, because WMF legal has stated that they categorically will not allow the "view deleted" right to be given to anyone who has not passed a community vetting process like RfA. That aside, when I patrol speedy nominations, I always wind up declining at least a few for various reasons (doesn't meet the criteria, already survived AfD, etc.) I really don't want someone able to actually pull the trigger and delete something until they have undergone that community review. SeraphimbladeTalk to me12:56, 31 May 2016 (UTC)
Oppose We cannot have people delete unless they are able to undelete. Undeleting comes with the ability to view deleted material. Viewing deleted materials is one of the most sensitive tools admins have, and it is not even logged. RfA allows us to determine community trust and I don't think we should circumvent it. HighInBC13:47, 31 May 2016 (UTC)
Oppose any further unbundling. Anybody who can be trusted with deletion should be an admin. —Kusma (t·c) 19:39, 31 May 2016 (UTC)
Oppose Lots of good rationales here. I support non-admin doing more things that don't use the bit, like closing discussions, "keep" AFDs and the like, but Delete is a sensitive tool, in some ways more powerful than the Block button as few people notice a bad Delete but everyone sees a bad Block. If you want to Delete, you probably need to go to RFA. Dennis Brown - 2¢17:40, 4 June 2016 (UTC)
Discussion (RfC: Unbundle the 'delete' userright)
Would need to check with a dev as to what would happen without the other tools such as browsearchive and deletedtext, as you want to include undelete functions without deletion viewing. — xaosfluxTalk03:58, 31 May 2016 (UTC)
It doesn't work. I just tested it on a WMF instance and even with the undelete right, without some other associated permissions it is not possible to access Special:Undelete in order to restore the page. The other permission required is deletedhistory, which when combined with undelete gives full access to deleted text as well. There doesn't seem to be an actual way of undeleting pages without viewing the associated revision and text of them. For what it's worth, some other projects have an eliminators user group with delete abilities, though this group usually requires a request period just like an RfA. As to the technical possibility of smalldelete, that should be do-able. Ajraddatz (talk) 04:35, 31 May 2016 (UTC)
I might be able to get behind a "deleter" group for new page patrol, but with severe limits. Only grant the delete right, and only on pages with a very small (perhaps less then 10) version history (like 'smalldelete' as opposed to 'bigdelete' in wgDeleteRevisionsLimit ) . — xaosfluxTalk04:06, 31 May 2016 (UTC)
@Music1201:CAT:CSD is actually one of the least-backlogged maint categories on Wikipedia. As you say, speedy-tagged pages are reviewed in a matter of hours; contrast this to WP:BL, where several backlogs are on the order of hundreds of thousands of pages long. I'm not seeing any special need for faster CSD reviewing (except, perhaps, G10s, which are already handled very quickly). Will a couple non-notable bands being on Wikipedia for a couple hours longer really harm anything? Kevin (aka L235·t·c) 04:19, 31 May 2016 (UTC)
I agree. If the right is restricted to very very new pages (created within 24 hours) and with less than 10 total edits, I'd be on board. I'd also add that it should be used only for the deletion of articles that need it now, such as G10 or G12. Others such as A7 should probably be left to administrators (in my opinion). ~Oshwah~(talk)(contribs)04:21, 31 May 2016 (UTC)
While I would like more people to have the ability to delete G10 pages, I would prefer to do this by recruiting more admins. If we unbundled a limited delete that only allowed people to delete per G10 then we would be bound to see instances where it was a good deletion, though an admin would have speedied it as A7 or some other code rather than G10. But there is a broader issue about unbundling speedy delete. AFD and MFD leave a trail in that there is a deletion debate which others can at leeast partly follow even if they can't see deleted edits. CSD is not about admins reading the consensus of a discussion, it is where we trust admins to delete per a set of policies. We need to be very sure who we trust with that right as deletion errors can be very damaging. ϢereSpielChequers08:54, 31 May 2016 (UTC)
I wonder if we could unbundle the other way; that is, maybe we could unbundle everything but deletion and undeletion, leaving admins with only those rights and have the other rights separately, so that WMF legal wouldn't require an RFA-like process for them. That could solve the frequently-mentioned problems with hostility at RFA as well as the legal issues, because because RFA would only grant deletion and undeletion rights. This would of course be a major change to the current user right system, and it would probably create its own issues that I'm not thinking of right now, but I don't think I've seen anyone suggest it before. KSFTC05:34, 4 June 2016 (UTC)
Recommend immediate close
Unfortunately, any proposal to give any kind of delete rights to non-admins will not pass muster with the legal team (and you simply can't give delete without undelete, since we all need to be able to fix our own goofs). This page from 2008 pretty much sums up all of the problems with doing this. I don't see the fact that these pages are very new would make any difference. Oiyarbepsy (talk) 05:13, 31 May 2016 (UTC)
Well it depends. Someone could propose unbundling it and a new separate Request for Deletion rights system. The issue isn't the separation, it's the fact that people want basically a shortcut around RFA for one of the two key things that RFAs filter. There's no problem proposing another RFA-lite system for people who just want the deletion tools without the blocking tools if people think that's actually workable. -- Ricky81682 (talk) 00:57, 3 June 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Maintenance tag removal: multiple issues
The recent proposal to include a "Learn how & when to remove this template message" link in maintenance tags was widely acclaimed. Now that it has been implemented for single maintenance tags, could something similar be included when two or more tags are bundled in the {{Multiple issues}} template? Compare, for example, the boxes at the top of this article containing the "Learn how & when..." link, with the multiple-issues box at this one which still gives no such suggestion: Noyster (talk),10:47, 2 June 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The name "Persian Gulf" is disputed (see Persian Gulf naming dispute) and although it is widely accepted in accordance with WP guidelines WP:WIAN, it is not used by Arab states. A recognised (by BGN, Google maps and various atlases) alternative name is "Arabian Gulf". As a compromise exception to guidelines:
Should the name be determined by the article content? For example, an article about an Arab entity would use the term "Arabian Gulf", while an article on a Persian/Iranian entity would use "Persian Gulf"?
Common English usage is Persian Gulf , more than that there is no consensus between many Arab countries to name it as Arabian Gulf . --Alborz Fallah (talk) 09:50, 7 June 2016 (UTC)
Agreed. Since there is no agreement by the countries in the area, but widespread historical and modern international recognition of the term "Persian Gulf", my sense is that we should stick with that but, where it makes sense, acknowledge the other options which also include "Arabo-Persian Gulf" and "the Gulf" to name just two more. Swapping between different terms is likely to cause confusion and could look like an artificial attempt at Wikipedian political correctness rather than following the majority use of English sources. --Bermicourt (talk) 09:54, 7 June 2016 (UTC)
WP:COMMONNAME applies here, and since this is English language Wikipedia, the common names in Arabic and Persian aren't relevant. I wouldn't object to "Arabian Gulf" being given as an alternative name in relevant contexts, or perhaps the neutral term "the Gulf" (where it's obvious which gulf) could be used linking to the article. E.g. "Bahrain is an island in the Persian (Arabian) Gulf" or "Bahrain is an island in the Gulf". Bazonka (talk) 10:03, 7 June 2016 (UTC)
It'd be easier, imho, were the RFC statement better stated. FrankB
No. WP:COMMONNAME applies. Google reports 11.4 million hits for "Persian Gulf" vs 0.4 million hits for "Arabian Gulf". (And the top three hits using "Arabian Gulf" are all Wikipedia!) That's 96.6% for Persian Gulf vs 3.4% for Arabian Gulf. An article may mention that the alternate name exists, but this should only be done in articles primarily focused on the Gulf or if there is some specific reason to mention the alternate name. It would typically be Undue Weight / Fringe for other articles to even mention that a rarely used alternate name exists. Alsee (talk) 12:59, 7 June 2016 (UTC) P.S. WP:COMMONNAME is technically about article titles, but the principle is valid regarding article text. We write Common-English text. Alsee (talk) 13:04, 7 June 2016 (UTC)
No – The common English name is "Persian Gulf". We don't need to go through contortions to accommodate the political desires of various countries. RGloucester — ☎15:35, 7 June 2016 (UTC)
No. WP:COMMONNAME applies. Breaking historical references in place for decades just because some group feels maligned is always idiotic, at the very least, since it creates confusion. • However, using the Template:R from historic name(edittalklinkshistory) as a template which creates a searchable and printable alternative name tagging per wikimarkup as a guide, and version allowing printworthiness of {{R from alternative name}} (whichever of the many versions of that is the last) can be used to categorize a redirect with the Arabian Gulf title. When printworthy, web crawlers will find it, making the link for google and BING, Yahoo, etc. Like many history and culture articles, how to support the two or more alternative names in the lead is well established. It just takes a little bit of thought to craft a phrasing using both.
No per everyone else, informing that the dispute exists is useful, using a largely unknown term is not. Where necessary, one can add 'known locally as', but the evidence is not very persuasive that the other term is anything like universally accepted in the region. Pincrete (talk) 22:12, 7 June 2016 (UTC)
'No It's not a bad compromise but it's unnecessary per COMMONNAME and it would be a little difficult to enforce, correctly. Chris Troutman (talk)22:53, 7 June 2016 (UTC)
No -- Commonname, and also we are not here to WP:RIGHTGREATWRONGS. When the common name changes, then we can change the page. Wikipedia is not the place to initiate that change. If some people prefer another name, even if they have the right to some weight by means of living in the area, well... tough. Wikipedia is not censored, and does not bow to minority views, however just their cause may be. Fieari (talk) 07:42, 8 June 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Redirect for last letter transposition?
Hey people,
would it be a good idea to make it so if someone enters a wiki search over a certain number of characters which doesn't have an article but which does if the last two letters were transposed, it would redirect to that one? If so, how would this be accomplished? Cheeseinacan (talk)
Try a 'site: https://en.wikipedia.org' prefix in Google or Bing, etc. Speaking as a computer engineer, switching end characters in a search string would take a very special (and odd) searching software. You'd pretty much have to customize it to the expected form of the data in an applications program, and web scripting (java, php, etc.) doesn't ever have access to enough local ram in the virtual machine they work within, to play games with the memory needs such a search would need. Good luck though! FrankB17:32, 7 June 2016 (UTC)
Try it: Search for "Abraham Linconl". It doesn't take you straight to Old Abe's article, but it does give you a page of results headed "Showing results for abraham lincoln. Search instead for abraham linconl." I think that's the right approach. Chuntuk (talk) 13:08, 9 June 2016 (UTC)
RfC: Preferred protocol for external links
NO CONSENSUS
Dragging this out of the archive because it is still listed on WP:CENT and WP:ANRFC. Multiple ways forward were suggested, but there is no consensus to proceed with any of the proposals. There was some confusion regarding the effects of option C, the "protocol-relative URLs": a few editors noted that options A and C are functionally the same, since // will force the current protocol, and Wikipedia pages all use HTTPS. A couple editors mentioned the previous RfC that agreed to use HTTPS with links to the Internet Archive and Google, noting that the same arguments at that discussion may apply to these proposals. The result of the previous RfC is not affected by the lack of consensus at this discussion, since the scopes of these two discussions aren't the same. Additionally, some editors did not see any need to standardize external link protocol in this fashion.
Overall, there was a general lack of interest towards this discussion, and as an uninvolved editor, I cannot discern any coherent consensus for any particular point of view. Mz7 (talk) 01:39, 12 June 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
As discussed at Wikipedia:Village pump (technical)/Archive 145#Preferred protocol for external links templates, there seems to be no consensus as to whether, if an external site uses both https and http, our links to it should use the former, the latter, or be in the protocol-agnostic form //example.com/foobar. This is particularly significant for templated links, such as those in {{TED speaker}}, but also applies to hand-crafted links.
I'll play. Support this option per prior RfC, which established clear consensus for HTTPS for links to Google and Internet Archive—until someone shows how these cases are substantially different from those and therefore need a new debate and separate consensus. ―Mandruss☎18:50, 8 April 2016 (UTC)
The privacy of our readers is very important, and there's no longer any drawback. There were only ever two problems with SSL. One was that not everything supported it, and two was that it was slower than unsafe HTTP. The slowness problem has been solved by advances in technology - even a $5 computer is now fast enough to do SSL with no slowdown. We don't have to worry about lack of support anymore either, since we're now SSL-only, so anyone whose browser doesn't support SSL can't see Wikipedia, so it doesn't matter if our links wouldn't work either. (And if they use some sort of proxy or similar tricks to make Wikipedia work, they can use the same thing to make the external links work.) Jackmcbarn (talk) 17:39, 29 May 2016 (UTC)
Most websites will upgrade the connection to https:// if the browser supports it, like Wikipedia does, and if we link to http:// websites that do not support https:// with https:// links, then those links will appear to be not working. Tom29739[talk]17:36, 13 April 2016 (UTC).
This RfC has nothing to do with websites that do not support HTTPS. Please read the intro. However, http://news.google.com does in fact upgrade to HTTPS, as you say. That would appear to change the issue somewhat. I wasn't involved in previous discussions, so I don't know whether that was considered there. ―Mandruss☎17:48, 13 April 2016 (UTC)
Update: The upgrade was apparently being done by my browser (Firefox), not by Google, because I had previously visited news.google.com in that browser using HTTPS. When I tried it in Microsoft Edge, which had never visited that site, it did not upgrade. ―Mandruss☎18:30, 13 April 2016 (UTC)
No reason to force the protocol on people; the encryption adds overhead and some people (e.g. on metered bandwidth) don't want it. Second preference is for 'a'; if we were to force one, it should be the secure one, per common sense. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 08:07, 12 April 2016 (UTC)
@SMcCandlish: One of us is misinformed. As I understand it, this option merely carries forward the existing protocol, which for Wikipedia is now always HTTPS. Thus, 'a' and 'c' are identical in effect, for links from this site. There is no option that does not "force" one protocol or the other; 'a' and 'c' "force" HTTPS and 'b' "forces" HTTP. ―Mandruss☎18:32, 12 April 2016 (UTC)
If you tell it "//", will it not try https://, and failing that, fall back to http://? I thought that was the point. I might well be misinformed. If it's just an alias for "https://", then yes, let's use that instead. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 20:01, 12 April 2016 (UTC)
AFAIK the IP etc are correct. Wikipedia:Protocol-relative URL are relative to the current protocol. So if you're accessing the page over HTTPS, HTTPS will be attempted. Some browser may have fall back options, but I'm not sure if these are exclusive to protocl relative URLs. However I still think this proposal makes the most sense and it's what I've always used (for HTTPS compatible sites) since before most wikimedia sites became HTTPS only. My reason is because while it's true AFAIK that via a combination of HSTS and 301 redirection HTTPS has been forced for most wikimedia sites since the middle of last year [2], in the past exceptions were made where this caused problems [3][4]. While I don't think HSTS has the concepts of exceptions (you could simply not send HSTS but that won't affect preload lists [5] nor those who already have it); not all browsers support HSTS and can often be disabled on the browser if you really want to. Once you take way HSTS, you only need to add exceptions to the 301 Redirection. I don't think this is particularly likely, but for all the controversy surrounding the WMF at times, IMO this is one case where we can resonably trust them to make the right decision about whether to stay HTTPS only for everyone. Also, while it would be trivial for mirrors etc to rewrite the links, even if they don't it makes most sense IMO for them to use protocol relative URLs so if the sites aren't HTTPS only and the person is viewing them using HTTP (perhaps because they can't use HTTPS so need to use HTTP supporting mirrors) they will go via HTTP to these other sites. And since this is not a disadvantage to us, as a free encyclopaedia it makes sense for us to choose the option providing the most utility to re-users. The only caveats are that I'm not sure if protocol relative URLs could cause any compatibility problems and that protocol-relative URLs when printed may remain as protocol relative. When these are typed in exactly, HTTP may be used even if the person was originally using HTTPS. Additionally, if a protocol relative URL is used in local file, it most likely won't work. (And if it did work, there's a fair chance it's going to default to HTTP.) However a decent browser page or other archival utility should intentionally rewrite the links hopefully to the correct protocol, just as they should for relative URLs. Ultimately these disadvantages seem to minor compared to the admitedly small benefit of using protocol relative URLs. Actually ideally we should use all 3. HTTP for any site which doesn't support HTTPS. HTTPS for sites which like wikipedia currently enforce HTTPS viaa HSTS and 301 redirection. Protocol relative for sites which support both. But the later 2 are probably too difficult for people to differentiate so I'll settle for protocol relative for all which support HTTPS. (If a site literally doesn't work when you try to access via HTTP then HTTPS links should be used.) Nil Einne (talk) 16:38, 23 May 2016 (UTC)
Meh
This seems to me to be creating a policy for the sake of having one. Why do we need a preference? Stifle (talk) 10:16, 16 May 2016 (UTC)
Agree with Stifle. What is the advantage to Wikipedia or its users of having any preference for one protocol or the other? So long as the URLs resolve to the correct page, I don't think it matters one way or the other. Surely there are more important things that we could be spending time on? Chuntuk (talk) 15:00, 16 May 2016 (UTC)
None of them. As dynamic as hyperlink formats can be, I think standardizing them would be a mistake. I would be down with some sort of system to see if the link is valid as it's formatted by the editor, though. Tpdwkouaa (talk) 14:36, 26 May 2016 (UTC)
This is the kind of thing that makes it hard for new editors to get involved in Wikipedia. I think this really doesn't need to be a thing. Nomader (talk) 20:11, 27 May 2016 (UTC)
Even websites that nominally support both http and https might be designed with one in mind, or more importantly, with one in mind for some purpose and the other for some other purpose. It's even possible to display entirely different content on the same website depending on the protocol used. – Finnusertop (talk ⋅ contribs) 00:02, 30 May 2016 (UTC)
Discussion of link protocols
Speedy close. Did you ignore or simply not see the below from the Archive 145 discussion:
@Pigsonthewing: The January 2014 link [Izno: inserted link] is that general consensus; the individual site consensuses have been specifically to modify all uses of those protocols for those websites to HTTPS via (semi-)automatic method (so as to explicitly suggest that the edits being made do not run afoul of WP:COSMETICBOT). You can probably make an argument after-the-fact, if questioned, that those RFCs show that COSMETICBOT is not infringed on w.r.t. TED links, but it is usually better to show such a priori.
How is that related to the RfC above? It seems pretty reasonable to ask how an external link should be formed. I saw the VPT discussion and it was a bunch of mumbo jumbo in response to a simple question—what is preferred? Johnuniq (talk) 12:16, 8 April 2016 (UTC)
Oops, I followed a link without noticing this is VPT. That is not a good place for an RfC. Please put it somewhere else because this is a high-turnover page focused on technical stuff, not interminable discussions. Johnuniq (talk) 12:19, 8 April 2016 (UTC)
Strong Oppose all, there is no community consensus to make this change for all external links. A straw poll on the Village Pump is not sufficient to justify bots rewriting a majority of articles. Bots will be blocked if they implement changes from this poll. The consensus from Archive 127 shows that link modifications are only approved for Google and Internet Archive links [6]. Nakon06:29, 5 May 2016 (UTC)
Straw man. This is not a proposal "to make this change for all external links", much less to have a bot do so. Since its asks whether the preference is A, B or C, stating "oppose all" is nonsensical. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits11:36, 13 May 2016 (UTC)
It's not nonsensical: to me, it's clear that Nakon wishes all links to be left alone, and not altered to any of the three suggestions. --Redrose64 (talk) 11:54, 13 May 2016 (UTC)
The proposal does not say that. Nor does the proposal say that it applies only to newly-added links, which would be another way of saying the same thing. Indeed, the proposal states "this is particularly significant for templated links" which implies that templates will be altered, and therefore, it is a proposal to alter existing links. --Redrose64 (talk) 19:39, 14 May 2016 (UTC)
Nor does it say that it is not a proposal to give everyone a free kitten. And please will you (or whoever is doing so) stop fucking up the list markup used here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:45, 26 May 2016 (UTC)
I've struck a problem with Option C. While using checklinks utility to clean up Apollo program ([7]), an editor set the archiveurl to the Option C form. But checklinks still reported the link as broken. When I made this edit to add the protocol to the URL, it worked, and checklinks then reported the link as working. Other tools may have the same problem. Hawkeye7 (talk) 21:17, 17 May 2016 (UTC)
Invalid Question
Please explain exactly why you think this is invalid (wrong place, consensus already established, begs the question, etc)
Invalid Question The question says "there seems to be no consensus" but the strong consensus as established in multiple discussions is to use HTTPS whenever and wherever possible (including external links) and to use HTTP only when HTTPS fails to bring up the desired page. (This is also posted in the wrong place, IMO, but that can be easily fixed with a move and a link to the new location.) --Guy Macon (talk) 15:10, 8 April 2016 (UTC)
This pretty much sums it up. Google and Archive.org support and encourage HTTPS connections, but so do Yahoo.com and a couple of other sites. For instance, HTTPS works for a lot of university websites, such as U of Chicago or Brown U, therefore we should link to the secure connection preferably. Only if HTTPS is not supported, we should leave HTTP. --bender235 (talk) 20:14, 13 April 2016 (UTC)
If the existence of multiple editors disagreeing with a consensus meant there was no consensus, we would never have a consensus on anything. ―Mandruss☎19:06, 29 May 2016 (UTC)
I was referring to the consensus that had already been established before you started this time-wasting exercise. It did not specifically address these cases, but we didn't need to because there is no substantial difference. See my !vote. Now you seem to be claiming that the fact that some disagree with the existing consensus shows that there is no consensus, and I think that's very flawed reasoning since consensus is almost never unanimous and rarely even close to unanimous. I was not involved in the original RfC, but I've scanned it and my sense is that there was enough knowledge present there to reach an acceptable resolution. I suggest that we accept it—at least until someone shows some actual, real-world unacceptable consequence of doing so. ―Mandruss☎15:28, 1 June 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Maybe talk pages should have some sort of indicator that says whether a particular user is online (to be specific, has one or more Wikipedia tabs open logged in to his/her account) or not. It's just a suggestion.98.195.88.33 (talk) 21:45, 1 June 2016 (UTC)
Making it optional would solve the privacy issues, but, without much knowledge of web development, I don't think there's any continuous communication between a browser and a server when a page is open, so the server would have no way of knowing whether the user is looking at the page; there's nothing preventing someone from requesting a web page and then closing the connection, anyway. I would guess that constant pings from every Wikipedia tab open anywhere would not be ideal either. KSFTC05:39, 4 June 2016 (UTC)
For this purpose, User:PleaseStand/User info is pretty good. It displays on the user page you are viewing the time that editor has most recently edited. If someone has edited 10 seconds ago, or a few minutes ago, it is likely that they are 'online'. – Finnusertop (talk ⋅ contribs) 23:56, 9 June 2016 (UTC)
A relatively resource light possibility would be to provide all logged in users a I'm Online button in their User interface which, only when pressed, added the user to a site wide list of online users. This list could be accessed by various methods including the API, and users would be instantly removed from the list on closing their last open Wikipedia tab or when manually clicking the button which would then read I'm Offline. That manual method doesn't need any continuous server-client communication, requires no hacks or special server side config (like Node.js for non blocking server events and stuff) and is entirely opt-in. The devil's in the details, but if it were wanted, it could be easily implemented without extraordinary measures.Fred Gandt · talk · contribs01:19, 10 June 2016 (UTC)
I would think Step 1 would be to show the need; i.e., what significant problem is solved? The OP didn't do so, and none of the responders have done so either. Without significant need we have unjustifiable feature creep. ―Mandruss☎01:31, 10 June 2016 (UTC)
I can't say I'm in favor of this proposal because this isn't intended as a social networking site. But if it were enabled I'd prefer a means to disable it for my talk page. Praemonitus (talk) 19:08, 13 June 2016 (UTC)
If it's just a tool of convenience, I might be amenable to a "Last contribution date/time" field being added to a user's Talk page and being auto-updated. While it's not a huge burden to check a user's contribution history, I'm sure I'm not the only one who's initiated a conversation at a user's Talk page only to find out they were essentially dormant. DonIago (talk) 19:40, 13 June 2016 (UTC)
Just a reminder that in just over a week at Wikimania there's going to be a cross-Wiki discussion about the systems of control of new pages. This is a round-table rather than a presentation or a lecture. On the agenda are reforms to the new article reviewing systems and ways to help new users better understand our content policies. Anyone who is going to Italy and would like to take part, please check out the conference schedule, and I look forward to seeing you there. --Kudpung กุดผึ้ง (talk) 16:44, 14 June 2016 (UTC)
The session is intended to focus on edit-review tools at all stages, not just the page creation stage, particularly around support for good-faith new editors. We hope to discuss everything from RC to Huggle. (The full conference schedule is at wm2016:Programme). Thanks for the help and interest. :) Quiddity (WMF) (talk) 21:07, 15 June 2016 (UTC)
search results - distinguish text in links
When searching for a term, sometimes you explicitely want to find a term that isn't already linked. (e.g. to find places that *could* link to something)
if i understand the proposal correctly, this is already supported today: prefix the search term with tilde ( ~ ): for instance, Special:Search/Washington links to Washington, but Special:Search/~Washington should show you articles containing the word, in either the text or the article name. you can even ask to see articles containing the search term in the text but do not contain some phrase in the article name (can be the search term or something else) by using "intitle:" together with "do not contain" (precede the search term with "-"): Special:Search/Washington -intitle:Washington. for more about search, see Help:Searching. if i did not understand the proposal correctly, assume that there was at least one more person who did not understand, and rephrase the proposal. peace - קיפודנחש (aka kipod) (talk) 19:05, 13 June 2016 (UTC)
It's nice to know that. I've been searching with a null field to get the search form, then entering the term. Thanks. Praemonitus (talk) 18:59, 16 June 2016 (UTC)
RFC on setting up a separate section for BLPs at requests for page protection
Support. The main task being done here is to fix the formatting of certain Wayback Machine links to use https and use the full version of the URL from WM. There was wide consensus to convert such links to https at this discussion. Additionally, around 5% of the edits will either remove a non-working archive link or replace it with an appropriate archive. That's obviously useful. The rest of the fixes affect a relatively small percentage of the total here, but they're all useful fixes to ensure all archive links are working properly. ~ RobTalk01:46, 18 June 2016 (UTC)
File:Barbra Streisand - 1966.jpg ... good to go?
Hi, I'm from the Norwegian Wikipedia, and I'm currently working on the Barbra Streisand article. I would like to use the Barbra Streisand - 1966.jpg file, but it was uploaded "by a user who is currently the subject of a contributor copyright investigation. As such, until the file is thoroughly investigated it should not be moved to Commons." However, it seems as though the investigation has ended, while there still is 132 pictures left. Could anyone with the right authority check the Streisand file to check if it's okay to upload on Commons? Torfilm (talk) 18:50, 19 June 2016 (UTC)
The CCI investigation is/was this one ... it looks like it rather fizzled out. The uploader, Wikiwatcher1 (who is presumed also to be user Light show) asserted that there was no copyright on publicity stills, Wikimedia legal advice came close to the same conclusion, but there was some haggling about the fine print (can we prove images were not registered/reregistered) and not a meeting of minds (uploader dealing in "publicity stills", wikimedia lawyers talking to "production stills". My feeling is that it is indeed good to go. But ping @Moonriddengirl:, who may be able to opine further. --Tagishsimon(talk)19:06, 19 June 2016 (UTC)
Highlighting free to read external links in scholarly references
The WP:OABOT project aims at enhancing citation templates with free to read links to references, when they are available.
We plan to change the visual appearance of many citation templates so we seek consensus here first - we need your input!
Concretely, we plan to change the style of links that are known to link to a free to read resource. Just like links to PDF files have a small PDF icon at the end, we plan to add a small logo indicating that a link is paywall-free. For instance, we know that all links defined by |arxiv= are free, so all citation templates using this parameter would become like this:
{{cite arXiv | collaboration = LIGO Scientific Collaboration and Virgo Collaboration | last1 = Abbott | first1 = Benjamin P. | arxiv=1602.03840 | title=Properties of the binary black hole merger GW150914 | date=11 February 2016}}
Abbott, Benjamin P.; et al. (LIGO Scientific Collaboration and Virgo Collaboration) (11 February 2016). "Properties of the binary black hole merger GW150914". arXiv:1602.03840
In this case, the free to read icon would appear without changing any of the template arguments - the Module:Citation/CS1 would be modified directly and this would affect all citation templates globally. We would make this change for other identifiers that are necessarily free to read, such as |pmc=. Technically, the icon would be inserted using CSS code (the same way PDF icons are currently displayed). It could replace the external link icon (->) to save space.
We also want to be able to add this icon on arguments that are not always free to read such as |url= or |doi=. To do so, we would need to change the template to indicate that the link is free, for instance by adding |doi-free=true or |doi-free=10.1016/S0168-0072(03)00052-6
{{Cite journal| doi = 10.1016/S0168-0072(03)00052-6| doi-free=true| issn = 0168-0072| volume = 124| issue = 1–3| pages = 71–106| last1 = Coquand| first1 = Thierry| last2 = Sambin| first2 = Giovanni| last3 = Smith| first3 = Jan| last4 = Valentini| first4 = Silvio| title = Inductively generated formal topologies| journal = Annals of Pure and Applied Logic| date = 2003-12-15}}
Coquand, Thierry; Sambin, Giovanni; Smith, Jan; Valentini, Silvio (2003-12-15). "Inductively generated formal topologies". Annals of Pure and Applied Logic124 (1-3): 71-106. doi:10.1016/S0168-0072(03)00052-6. ISSN0168-0072.
Watchlist usernames in descending edit count sequence
example
In Preferences, Watchlist tab, the option "Expand watchlist to show all changes, not just the most recent" shows the usernames in ascending edit count sequence. Assuming we're most interested in the highest contributors, it would be more useful to sort in descending edit count sequence instead. Then you wouldn't spend time scanning to the end of the list. You would start at the beginning and scan until you deemed the edit counts too small to continue. Worth doing? ―Mandruss☎02:16, 20 June 2016 (UTC)
@Xaosflux: With that option enabled, you also get a list of the contributors to each page, on that date, with edit counts when they exceed 1. Those lists are what I'm referring to. You might enable the option and have a look. ―Mandruss☎03:43, 20 June 2016 (UTC)
OK, I see now - combination of "group changes" and "expand watchlist to show" has to be on for that behavior. - I uploaded a screenshot above. — xaosfluxTalk03:57, 20 June 2016 (UTC)
I think the next question is to determine where this is being generated - anyone know without climbinis g though the code? — xaosfluxTalk03:59, 20 June 2016 (UTC)
And the list can go to two, three, or more lines, depending on the number of usernames and the width of the window. Since it doesn't end in a predictable or consistent location, finding the end takes a non-trivial amount of scanning. One occurrence is nothing, but this stuff adds up. ―Mandruss☎04:58, 20 June 2016 (UTC)
not sure why do you claim that the users are listed in ascending or descending order of # of contributions. did you read it in the docs somewhere, or is it an observation? if the latter, maybe you should look for one or two more samples - this simply does not seem to be true.
i can't quite understand the order in which users are listed in this mode - it may be completely arbitrary, but i'm pretty sure it has nothing to do with # of contributions. i do not think this number is readily available, and obtaining it just so the names can be sorted by it seems excessive - it will have significant cost, and no gain whatsoever. peace - קיפודנחש (aka kipod) (talk) 05:22, 20 June 2016 (UTC)
Maybe we're looking at different things. Here's another real-life example of the list: [Lowercase sigmabot III; Neutrality; 71.182.239.232; DHeyward; WWGB; Computationsaysno; Shearonink (2×); Ad Orientem (2×); Victorgrigas (2×); Wnt (2×); Penwhale (3×); Felsic2 (3×); MrX (4×); Pincrete (5×); Ianmacm (5×); Alanscottwalker (6×); Mandruss (15×); InedibleHulk (15×)]. The number is clearly readily available, as I see it displayed on my screen. I claim it is in ascending edit count sequence because it is in ascending edit count sequence (I'm pretty good at this kind of thing). Just in case, I have double-checked my entire watchlist, and every list is in ascending sequence. I believe the significant cost is already being spent. Thanks. ―Mandruss☎05:31, 20 June 2016 (UTC)
i think there's some lingo confusion here. in wp lingo, "edit count" usually meas the total number of edits the user made on the specific wiki, since she initially registered. the "edit count" mentioned in this thread, is something else entirely: it's the number of edits this user made in one specific day, on one specific page. this explains the previous confusion. that said, the suggestion makes sense, but i don't think it makes sense to behave differently on enwiki than anywhere else, so i think something like this is more appropriate on phabricator than enwiki proposal page. peace - קיפודנחש (aka kipod) (talk) 17:42, 20 June 2016 (UTC)
Ah, that clarification helps! I don't think the sorting matters that much. I think I'd most like to see the order by who most recently changed the page personally, but I don't really care any which way. --Izno (talk) 17:46, 20 June 2016 (UTC)
To better browsing, better edits, and decrease in work load
Give better instruction-pages, such-as code-templates etc, and please make them easy-to find.
Please add better site-maps, content, index etc of everything, so-that, at-a-glance the big-picture as-well the exact-topics could be found easily. (like book-contents showing chapters and sub-chapters at-one-time).
On each instruction page, please use more flow-chart, small animated instructions, and brief simple summaries or abstracts.
Troubles take place the most , when I know a feature on wikipedia, and want to use it, but do-not know the feature's name at all (say a "gallery", or a "infobox", etc ), or do-not know how-to use that feature (say a table, or a colored text, etc). So, there could be a feature to inspect the "nature" of an object on wiki-pages, i.e. "this is called hat note", "this is called info-box", "this is called paragraph", etc, and showing how to use associated wiki-text-codes, visual-edit options, etc to create such items. Also provide a link on left-hand task-bar, to access a list of features on wiki.
If an user keeps a question/problem/suggestion on a wrong/irrelevant help-page or forum, (upto a limit of tolerance) , that talk could be moved/copied to the right helpdesk(s)/portal(s)/categories, with a button.
I've taken the liberty of removing the bolding from your original post to increase readability. (Per WP:TPO: Some examples of appropriately editing others' comments: ...Fixing format errors that render material difficult to read.) Feel free to revert. Enterprisey (talk!) (formerly APerson)17:38, 21 June 2016 (UTC)
Disclosures in citations for sites that scan for ad-blocking software
Due to the increasingly heavy use of ad-blocking software for various reasons (primarily security and maintaining web browser performance), and the similarly increasing use of counter-measures against users who employ them, I feel that citations should have notices to inform users if a particular source employs technical measures to scan for ad-blocking software, and generate messages or outright restrict access to content if an ad-blocker is detected. We already do something similar for sites that employ paywalls or require registration (i.e. {{subscription required}}); An explicit requirement to view ads in order to access content should, due to its prominence, also be disclosed in a similar manner.
I do not know how we would word this, but it would be presented similarly to the Subscription required notice, and would only be used on citations that restrict access to content or present notices if the web page attempts to detect ad-blocking software. Ad-blocking is typically used as a privacy measure, and these scans cause the execution of scripts intended to detect for ad-blockers by reading its behaviour. ViperSnake151 Talk 19:40, 7 June 2016 (UTC)
Oppose: Editors are free to have whatever principles concerning internet advertising they like, but their reluctance to verify something because of ads (or ad-blocking detectors) has zero effect on the verifiability of a source. Whatever their opinions on ad-blocking, we have agreed not to change Wikipedia policies to make a point. The reason we have {{subscription required}} is because cost or registration can be a real-life hindrance for verifiability (but as WP:PAYWALL notes, does not entail that verification will fail). The presence of ads (or ad-blocking detection) on a website on the other hand, has no negative effect on the verifiability of the source. Security issues are already covered by WP:ELNO; and ad-blocker detectors probably don't amount to "malicious scripts". There is nothing that readers need to be "warned" about except for their own principles (of which of course they are already aware). – Finnusertop (talk ⋅ contribs) 20:08, 7 June 2016 (UTC)
Well but wait User:Finnusertop -- I agree that these sources can be used as citations (maybe), but if a site is acting agressively against user's interests, isn't it pretty unfriendly to not at least warn our readers? As a thought experiment, suppose there's a site that that reliably verifies a fact, but going to that site causes an unpreventable installation of malware that copies all that user's files to the Russian Mafia and then formats her hard drive? We wouldn't use that site as a ref at all, let alone do so without warning people, right? Suppose it was otherwise reliable proof of the fact, and even assuming it was an important fact and it was the only reliable verification (again, thought experiment) -- we still wouldn't. Right? I hope. I don't know where the adware-blocking sites fit on the continuum "Russian Mafia, then format <--> No Problem", but since the editor said "Ad-blocking is typically used as a privacy measure" I'd like to hear more about how much privacy loss we are talking about before signing onto the we-don't-need-to-worry-about-this-at-all ticket. Herostratus (talk) 00:19, 9 June 2016 (UTC)
I don't think we should go to the enormous effort of flagging all the references Wikipedia makes to sites using ad blockers today (which might be different to the number using them tomorrow) on the basis of some absurd strawman about malware-toting Russian Mafiosi. There are any number of behaviours a website might adopt (at any time) that a reader might not like. Wikipedia can't be expected to police that. All we can do is say "this site verifies this statement" (keeping that up to date for millions of links is more than enough work to do). Chuntuk (talk) 13:01, 9 June 2016 (UTC)
Regarding Herostratus's claim "if a site is acting aggressively against user's interests", As the Adblock Plus page says,[8] "ads fuel a lot of the content we enjoy for free online". One could argue that if a significant number of ad-supported websites such as Google, Youtube and Facebook shut down because of declining ad revenues, that would be "against user's interests". I personally really like Adblock Plus's "General criteria for Ads that shall be treated as Acceptable Ads"[9] as an acceptable compromise between blocking all ads and blocking no ads. --Guy Macon (talk) 00:39, 10 June 2016 (UTC)
Oppose. This is going to be an entire waste of time if a website changes its mind about subscription notices and we have to revise all references to a particular citation for whatever point is going on here. And why sites that search for ad blocking software? Should we identify webpages with poor privacy policies? Webpages that have pop up ads? Webpages with excessive or third-party scripting? If this is that offensive, then propose a remedy for a particular website's links or propose the removal of web links to a particular page. Or else blacklist the site itself if you want that done. -- Ricky81682 (talk) 09:07, 9 June 2016 (UTC)
Oppose: First, the question asked is biased. "Ad-blocking is typically used as a privacy measure" is almost certainly factually incorrect. The most common reason is most likely reducing user annoyance. Compare the websites for the ad blockers Adblock Plus[10] ("Surf the web without annoying ads! ...Unobtrusive ads aren't being blocked...") and Privacy Badger[11] ("Privacy Badger is a browser add-on that stops advertisers and other third-party trackers from secretly tracking where you go and what pages you look at on the web.") Adblock Plus tries to block the annoying ads and let the unobtrusive ads through, while Privacy Badger tries to block the ads that track you and let the ones that don't through. The web is full of sites that use counter-measures to try to defeat Adblock Plus, but I have never heard of any site that tries to defeat Privacy Badger. Second, ad blockers are a terrible way to protect privacy. They address another issue entirely and any privacy benefits are an accidental side effect. Third, it is not Wikipedia's place to take any position on the ongoing arms race between ad blockers and sites that are supported by advertising. Unlike paywalls, ads do not interfere with verifiability. --Guy Macon (talk) 14:05, 9 June 2016 (UTC)
@Guy Macon: It doesn't matter if someone is using Adblock Plus or Privacy Badger, the website may still block you for using Privacy Badger if their ads happen to be blocked as trackers, which is pretty common for the big ad networks. Personally, I use uBlock Origin with filter lists to block ads and trackers. Anyway, I agree this idea is not feasible. An alternative could be to add pre-emptive archiving, e.g. at WebCite. It wouldn't be the most prominent link with |deadurl=no, and it would be useful for preservation anyway. nyuszika7h (talk) 10:27, 11 June 2016 (UTC)
I don't think that paywalls, ad-blocker-scanning, country-based restrictions, or anything like that interferes with verifiability. You personally may not be able to verify the source if you won't or can't pay for it, if you won't or can't use the software settings that the website prefers, you won't or can't access the internet from a country that the website approves of, etc., but verifiability isn't about what's possible for you personally. It's about what's possible for someone (someone who is not the person originally adding that material), not what's possible for every single reader. WhatamIdoing (talk) 04:48, 15 June 2016 (UTC)
Oppose. In an ideal world, it may work, but it'd just take too long to tag everything with it, unless there's a sort of list that automatically adds it and removes it (such as |publisher=Forbes, |publisher=Wired). Also, if this were to be implemented, where would the line be drawn for other things? As Ricky81682 said, would we also notify for popup ads, etc? Anarchyte(work | talk)07:24, 11 June 2016 (UTC)
No objection I don't think this is a critical template, but there's nothing wrong with having it and using it when someone believes that it's appropriate. {{Subscription needed}} isn't used very often, and I expect this would be less popular, but it's not harmful. WhatamIdoing (talk) 04:48, 15 June 2016 (UTC)
Oppose, these don't seem to have taken off much. They're pretty easily circumvented with Noscript or Greasemonkey/Tampermonkey scripts anyway, and those scripts are readily available. SeraphimbladeTalk to me17:47, 22 June 2016 (UTC)
Two new maintenance tags
I had a suggesion that there should be a maintainance tag that said - this article contains links that are dead (or which link to pages that dont exist) and This article has external referances that are in a language other than english --VarunFEB2003Talk • Contribs • Guestbook14:25, 21 June 2016 (UTC)
@VarunFEB2003: We don't have a template for "this article contains links that are dead", probably because it's vague (how would people know which are the good links and which the dead?). What we do have is {{dead link}} which should be applied to those specific links that are non-working. However, if those links are not used as references, but are merely entries in a "External links" section, and there is no way of updating them to a working link, normal practice is simply to remove them, see WP:ELDEAD.
Regarding non-English external links - again, each external link should be considered separately, so an article-wide template isn't appropriate. Not all non-English external links are problematic, see WP:NONENGEL; consider each non-English external link in turn, decide whether it is useful or not. If not, remove it; if useful, add an appropriate language marker such as {{es icon}} for a Spanish-language external link. --Redrose64 (talk) 22:14, 21 June 2016 (UTC)
These seem like minor issues that are best dealt with using inline tags. There's already enough pages cluttered up with maintenance tags at the top. Praemonitus (talk) 18:53, 23 June 2016 (UTC)
I'm inclined to agree with above. What problems are these tags intended to solve, especially when it appears that they'd be general tags referring to specific problems? DonIago (talk) 19:37, 23 June 2016 (UTC)
- which would add the 'ref' tags, *and* extract a title from the link. this might seem trivial but it would let editors keep their focus on the article, and reduce the laboriousness in actually adding the link. It would result in titles being obscure file names sometimes, but I think it would be the lesser evil, given that it would allow lazy people to actually source more links in the first place. (laziness is really about keeping focus on something else and conserving energy) — Preceding unsigned comment added by Fmadd (talk • contribs) 20:57, 17 June 2016
You seem to be asking for lots of new features in recent days, and rarely sign your posts; also, it's not always easy to work out what you are asking for. But Wikipedia templates cannot "extract a title from the link" because the title is not part of the link. Also, <ref>...</ref> tags and templates don't work as expected if you pump them full of extra spaces. --Redrose64 (talk) 22:19, 17 June 2016 (UTC)
I'm suggesting that at worst it just uses the filename, (which is sometimes related to the title.) I can also imagine a commonly useful function for getting a title from a web-page. Computers are here to save us from repetitive tasks, dotting I's and crossing T's. Fmadd (talk) 23:03, 17 June 2016 (UTC)
Fmadd, what you want is available in the mw:citoid service. Switch to the visual editor to try it out: Open an article, find and click on the pencil icon in the upper right corner, and wait a moment until it transforms into something that looks like a modern word processor. The "Cite" button in the middle of the toolbar has an "Automatic" setting that provides excellent citations to some popular sources (e.g., PubMed, The New York Times and Google Books) and will extract a title for nearly all (non-pdf) URLs.
Let me just echo the suggestion - I use the VE editor for references and it does more than what you just requested - much more, and does so easier than your proposal.--S Philbrick(Talk)02:58, 18 June 2016 (UTC)
User:Ark25/RefScript. Fmadd, I use Ark25's reference generator. I don't have to switch to VE. And it generates {{cite}} references with the click of a button, extracting the title from almost any link and filling up many of the parameters without any issue. Positives: Saves a lot of time. Negatives: you need to double check stuff (including the name of the reference which is unusually long; I shorten that) and sometimes, where the news link does not have appropriate meta, some of the parameters remain unfilled. Also, if you are referring books or non-webnews stuff, the reference generator would still generate a cite web instead of a cite book or relevant cite template. You would need to manually change that, but that still saves a lot of time. Try it out and tell me how you found it. Works amazing for me. Lourdes00:57, 24 June 2016 (UTC)
Mobile Main Page changes
I don't mind having some extra options but please bear in mind that there are a wide range of screen sizes. In my household, these range from the 4 inches of the Galaxy Ace 2 through the 6 inches of the iPhone 6+, the 10 inches of the Galaxy Tab, 13 inches of multiple Chromebooks all the way up to my current 2 x 21 inch dual monitor setup. One size does not fit all. Anyway, my main point is that I noticed just today that the mobile view had changed. I'm used to viewing it on my iPhone 6+ while commuting. Usually, the main page shows the featured article with the ITN section then following underneath. The other sections are not shown. But today, for the first time, the mobile view (https://en.m.wikipedia.org) shows all the sections in a compressed version of the standard main screen. This doesn't work very well because there isn't enough space to show multiple columns. Who controls this and where do they hang out? I'd like to provide some feedback... Andrew D. (talk) 13:05, 24 June 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi everyone. I'm a basque wikipedian and I just saw on the panel "Wikipedia languages" that Basque Wikipedia (Euskara) is listed on the "More than 50,000 articles" section. I'm congratulated to tell you that yesterday Basque Wikipedia completed its 250.000 article so I think it should be now on the "More than 250,000 articles" section. Thanks.
Euskaldunaa (talk) 11:37, 24 June 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Interactive chess boards
There is a clear consensus to support the general proposal of enabling interactive chess boards on the English Wikipedia. Editors supported the proposal because it could help make chess articles more accessible by allowing readers to step forwards and backwards through games, at their own pace (closely paraphrasing Maproom). The technical implementation of interactive chess boards will need further discussion. Cunard (talk) 04:02, 18 July 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I would like to see a chess widget in chess articles which allow you to go through the moves as exists in other sites.
Peace. — Preceding unsigned comment added by 37.46.38.33 (talk) 23:07, 11 May 2016
What encyclopedic benefit would this extra utility offer? See what Wikipedia is not before answering.
As a keen chess player, code wrangler with a bent for UI and UX, and general autodidact, I can see value in interactive resources that assist reader's understanding. But, wouldn't simple animated gifs be enough? Fred Gandt · talk · contribs23:54, 11 May 2016 (UTC)
A chessboard, programmed using standard notation, could provide an alt automagically, but that's about the only benefit. You might also be able to allow users to consider variations, but that's of questionable value in chess, I suppose. --Izno (talk) 00:25, 12 May 2016 (UTC)
This is probably possible using mw:Extension:Graph, and if it not is currently possible the plugins can installed to make it possible, as d3 or some variant is used in the backend.
See:
I don't think Animated gifs provide the same level of help, given the desire to "scroll" through the game. Nothing really interactive here other than being able to take steps backwards and forwards.(In fact I'd like to be able to do this with Animated gifs) Naraht (talk) 14:22, 12 May 2016 (UTC)
This does add encyclopedic value, the same way that video or audio do. Otherwise there would be no need for anything aside from static images or text in any article. It would also add a nice way for readers to have a more interesting view of chess articles or gain a better understanding of them. In any case, even if wikipedia doesn't see any use for it, this would certainly be very useful for wikiversity.
197.218.80.220 (talk) 14:09, 12 May 2016 (UTC)
Support: This would add value to the chess articles on Wikipedia by letting users play through games and game fragments at their own pace without having to set up the position on a chessboard. Strawberry4Ever (talk) 15:03, 12 May 2016 (UTC)
I've had enough of your filthy attitude kipod; this comment was added in good faith at the start of a thread about implementing interactive chess on Wikipedia. I simply thought it worth mentioning that there exists some software that might be useful. It was not a suggestion that we should use it (as-is at least) or that we should even be using anything like it. Polite conversation on any subject should be open to all manner of input that is quite obviously relevant, as it may inspire/reveal paths worth following. However, since you joined this thread (and another linked discussion), all I (personally) have received from you is negativity; you are targeting me and anything I do or say with complaint. I would ask that you act more in accordance with the best interests of the project, and keep your personal issues to yourself. Hypocritical of me to discuss this with you on a public stage? If I am attacked in public, I shall respond in public. That is all I have to say on this matter. Fred Gandt · talk · contribs17:12, 1 June 2016 (UTC)
Support. It would make many chess articles more accessible, by allowing readers to step forwards and backwards through games, at their own pace. It would also be much less work for editors than animated gifs: you just include the display widget (or template, or whatever it becomes) along with a game record, instead of having to create an animated gif with 30-odd frames. Maproom (talk) 21:29, 12 May 2016 (UTC)
Support gifs don't have the ability to scroll through or stay on a particular ply for a particular amount of time. For people reading about a particular game, being able to analyze the board for as long as they wish is highly encyclopedic as they can look at it and come to their own conclusions about the value of a particular move. Further, it allows editors to discuss particular moves and readers to look at them on a board as they read an article. Wugapodes (talk) 18:23, 13 May 2016 (UTC)
Support. This would have tremendous encyclopedic benefit for wikipedia's chess articles. We talked about this a while ago but somewhere along the line we lost momentum. What would we need to do to implement Kipod Nakhash's script or similar on English wikipedia? Ideally we'd want to be able to use it for side lines as well, like the one they use at chessbase.com (sample page). MaxBrowne (talk) 02:15, 18 May 2016 (UTC)
Comment. While I can't say I've decided one way or another yet, this proposal is very exiting. Above, What Wikipedia is not was cited, and looking through it I really can't find any reasons why this proposal would be disruptive in that sense. Frankly, what Wikipedia is not, in my mind, is just a simple encyclopedia. Adding something like this could be a step towards redefining how we compile meaningful information, and I don't think it should automatically be discounted just because it could't exist in a book. Tpdwkouaa (talk) 01:28, 19 May 2016 (UTC)
Comment FTR and Support: I'd just like to add for the record that my citing NOT was only aimed to ground the proposal before it flew ahead with grand notions contrary to NOTHOWTO - which would could almost certainly end in political opposition. I personally agree with Tpdwkouaa (and others), would go a long way further and would love to see a more aggressive move away from treating Wikipedia like a paper bound encyclopedia, but that's just my personal opinion, and not the current consensus (I disagree with consensus quite often). As long as this functionality doesn't get too fancy, and is purely used to visually demonstrate what is practically impossible to describe any other way, I think the proposal can stand against opposition based on it not being encyclopedic. Technically, it can be a walk in the park; HTML5, JS and CSS make the web an almost magical place; where there's a will, there's a way. Fred Gandt · talk · contribs02:31, 19 May 2016 (UTC)
Strong support In this day and age people should not have to whip out a chess set in order to understand an article like Modern Benoni. An interactive chess board would motivate me to write more articles like that. Cobblet (talk) 16:47, 21 May 2016 (UTC)
Support I've gommented, but I haven't formally said I support the idea yet... Two things to think about. 1) GPL and 2) what should the readers for the Blind do with the gadget?Naraht (talk) 20:43, 21 May 2016 (UTC)
I've added {{bump}} to the thread to keep it alive. I think it best we maintain the conversation here for a while, since it's not a trivial proposal (additions to MW JS and CSS), and although I haven't helped by stalling the proceedings (nearly there!), it still needs input from many more users before there's any chance of a technical implementation being even considered for site wide adoption. Fred Gandt · talk · contribs16:34, 28 May 2016 (UTC)
I would suggest the valuable outcome of this thread is the demonstrated support for the idea in general, and that it served as the impetus to move forward with development. As for the specific implementation, when a plan is ready to go, I think it would make more sense to start a new thread focused on that proposal, pointing to the demo. This thread is already quite long and diffuse, making it difficult to get new people to read it/participate. Once there's a proposal ready to go, people won't need to know the process which led to it (to me, too much contextualization can make it seem more confusing/cumbersome than it needs to be). I started the other page to continue discussion, work out features/bugs/parameters, and work on developing a coherent proposal, operating on the assumption that a clear proposal for sitewide implementation is not imminent (i.e. there's more to the proposal than finishing a prototype). — Rhododendritestalk \\ 17:37, 28 May 2016 (UTC)
I agree with Rhododendrites. There's clear consensus for something like this to be attempted which is great. We should plan the project somewhere else, and when it' done bring it back here for an RfC to get consensus to add it to MW. Wugapodes[thɔk][kantʃɻɪbz]18:02, 28 May 2016 (UTC)
I would prefer the development process to be more immediately public than off and away in a quiet corner; we could work on the perfect proposal for months only to find that with the wider input of others it requires either massive reworking, or collapses. Since this topic is already out in the open, we can more quickly get a basic idea of how to proceed by tagging a child section (TBA) with an RfC and encourage readers to see how, why and when the proposal came about without explaining it all somewhere-or-when else. However, maybe that's just me; to me, it's simply more efficient to keep the ball rolling than to pick it up, put it on a shelf and dust it every now and then for a while, then take it back off and kick it. We can always collapse some of the junk, and create new sections as we go. Fred Gandt · talk · contribs18:27, 28 May 2016 (UTC)
I think that presuming Chess is done that Go would be reasonable. Not sure of others beyond that. Maybe draughts/checkers, maybe Chinese Chess.Naraht (talk) 15:23, 12 May 2016 (UTC)
Thank you, Redrose64. Some embeddable Go widgets are described here, including Eidogo, which uses Javascript. Eidogo is widely used, for instance in the main English-language Go forum, e.g.here. Maproom (talk) 20:32, 12 May 2016 (UTC)
I'd strongly urge all those taking part in this discussion to view (and play around with) the interactive lead image at Juego de la vida which should give a good idea of just how much is possible with Mediawiki, as well as a feel for what an article containing an interactive .js game board actually looks and feels like. ‑ Iridescent13:29, 14 May 2016 (UTC)
Iridescent Do you have any idea why that interactive tool is in the Spanish Wikipedia but not in the English Wikipedia? In English at Conway's Game of Life there are non-interactive images. Is there any barrier to copying that to English Wikipedia?
Different attitudes towards embedding auto-running javascripts on Wikipedia pages, which is something the en-wiki community has always been extremely wary about as it slows down page load times and introduces security vulnerabilities. This and this were the discussions in which the proposal were blocked. User:Felipe Schenone is the guy you want to talk to about getting a chess version written, although bear in mind that enabling it here would probably need explicit authority from the WMF devs and is likely to attract fierce opposition. ‑ Iridescent16:51, 16 May 2016 (UTC)
Hi, thanks for the mention Iridescent. I recently returned from the MediaWiki Hackathon in Jerusalem, where I worked next to Brion Vibber, Lead Software Architect for the Wikimedia Foundation, on the best way to include JavaScript widgets into Wikipedia articles. The issue is being tracked at https://phabricator.wikimedia.org/T131436 My old proposal here at the Village Pump has now evolved into the WikiWidgets project, which requires only a single line added to MediaWiki:Common.js in order to start working here at the English Wikipedia. Regarding the chess widget, I just added it to the list of requested widgets at the WikiWidgets project page, but I'm currently working on two others, so I won't promise anything. However, I checked the EidoGo source, and I may be able to turn it into a WikiWidget. I will keep you updated about this, but even if I do adapt it, the widget will not go live in the English Wikipedia unless the larger WikiWidgets project is accepted by the community. Cheers! --Felipe (talk) 17:48, 16 May 2016 (UTC)
@Felipe Schenone and Iridescent: Thanks both of you. I was unaware of these previous discussions and proposals. If the issue is raised again, then I think it would be worth reconsideration. I cannot imagine English Wikipedia community support for this right now just because of general community fear of encroachment but if there is a time when conversation can be more peaceful then I think people would want the benefits of this option. Blue Rasberry (talk)14:14, 17 May 2016 (UTC)
At a guess, you'd need to set up a process akin to WP:BRFA to vet and approve everything before it went live. As well as the fear over security vulnerabilities, bear in mind that English (and to a lesser extent French) Wikipedia has issues which don't exist to the same degree for the other language projects, in that Wikipedia is the primary source of information for much of Africa and Asia, where internet connections are often very slow and data can be heavily metered. Thus, anything which significantly adds to page load has the potential to have significant impact on the very people the WMF are trying hardest to reach, since if it's taking too long to load the pages they'll just give up. Someone from the WMF will no doubt have the figures. ‑ Iridescent15:45, 17 May 2016 (UTC)
The scripts could (and would, most likely) be excluded from loading in mobile view. This would largely avoid the issues you're concerned about, I think, as it is generally only mobile data that is so tightly metered. — This, that and the other (talk)09:35, 22 May 2016 (UTC)
@This (belatedly, sorry only just noticed this), this is something where the WMF's uncomfortably close relationship with Google will be an advantage, as they've already done the legwork with regards to bandwidth and metering issues so the figures should be easy to come by. As I understand it, the issue isn't just data metering, but that internet connections in much of Africa and Asia (and a surprising proportion of the West as well, particularly rural parts of the US and Canada; even in relatively high-density and high-tech cities like London, download speeds are often incredibly low) still work at dial-up speeds, so anything which adds significantly to load times will likely cause readers to give up waiting. (As a concrete example, Google allows background-downloading YouTube videos for offline viewing in India, as their research showed a staggering proportion of users there got bored waiting for buffering to complete.) I've no idea how much embedding widgets would add to page load times (paging RexxS, who generally seems to know these things.) ‑ Iridescent17:00, 1 June 2016 (UTC)
@Iridescent: I've had a look at the widget on the Spanish Wikipedia and it's really no bigger than a comparably sized image. I've created Java-based widgets in the past and they tend to be no more than a few tens of kilobytes in size, so I've no reason to suspect that a JavaScript-based widget would be a lot more. It's not like there's any content being streamed, as all of the work is done in the client browser after the initial download as far as I've been able to ascertain. Perhaps Felipe can confirm my impressions? If I'm right, there really is no issue with data usage: anywhere you can get static images, you'll have no problem getting these sort of widgets. --RexxS (talk) 18:48, 1 June 2016 (UTC)
@RexxS: Vivarium, the widget at the Game of life article in the Spanish Wikipedia, has two files: a 25 KB JavaScript file and a 4 KB CSS file. Formicarium, the widget at the Langton's ant article, has a 29 KB JavaScript file and a 4 KB CSS file. There is also a 4 KB initialisation script. So adding up and rounding up, loading a widget costs 50 KB. They both are pure client-side. Future widgets are likely to be similar. Cheers! --Felipe (talk) 22:17, 1 June 2016 (UTC)
PGN viewer 1
trying to answer some of the question asked above, plus some additional information:
i did a demo on testwiki last round to demonstrate the implementation, and i'll try to describe it here:
enwiki deployment recipe
add a hidden gadget. this adds the script and the css to RL, but does not actually load it for any user, so there is practically no extra load/bloat for pages not containing chess games
add 2 lines to common.js, such that after a page finish loading, it checks if the page contains games (by testing for some specific CSS class), and loads the viewer if needed
(maybe) add a couple of lines to common.css and/or to mediawiki:noscript.css, to support correct display for readers with and without JS.
create a template that displays the viewer for readers with JS enabled, or the PGN for readers with no/disabled JS.
viewer features / behavior
it is purely a game viewer: it is not meant to, and cannot, be used to play chess. it just shows previously played games using the games' PGN
like any other pgn viewer, it has forward, backward, jump to a move, and animate ("autoplay") buttons. (it also has a somewhat unusual feature: it can rotate the board to show the game from the black POV, though i am not sure how useful this is).
a single viewer can display any number of games, using HTML selector, and multiple viewers can exist on one page. an example can be seen on this page on hewiki, which contains every single game from Tata Steel Chess Tournament of 2013 - one viewer per round, containing all the round's games (note that the games are contained in collapsed elements - expand to see the viewer).
it supports FEN for initial position, so in addition to traditional games, it can be used, e.g,, for chess problems, or for Chess960
to support the chess community on hewiki, an editor can add a line to her personal JS page, and then the viewer shows one more button, to generate Template:Chess diagram for the currently showing position
the source is about 928 lines of JS and ~20 lines of CSS, weighs about 29 KB (not minified - with RL i expect it to be significantly less). it can be seen here: he:Mediawiki:Common.js/pgn.js
@קיפודנחש: Thanks for the overview. Some clarifications/questions:
It would be opt-in through a user's preferences (enabling a gadget)?
If so, what, if anything, would be displayed for a user who does not have it enabled?
When you say it may require adding two lines to common.js, you do mean MediaWiki:Common.js, correct? (as opposed to me adding it as a user script to my own common.js)
If necessary, would it work as a script enabled on an individual user basis? (this is not ideal, of course -- more for my own curiosity if it would work without modifying sitewide settings) — Rhododendritestalk \\ 13:45, 18 May 2016 (UTC)
answers:
i do not think this makes sense as an opt-in. opt-in features make sense for interface and behavior, not for content. there is an "inbuilt" opt-in, which is enabling JS on the browser. this is similar to other content-related behaviors, such as collapsible elements
as described above, users with no/disabled JS see the raw PGN. we currently display raw PGN in many chess-related articles.
this is possible, for demonstration purposes. it requires some work setting this up and testing it on this wiki, and i'll try to set up local demo (which will require loading a personal script) sometime soon.
@קיפודנחש: It looks like there's support for this, with no compelling arguments in opposition and no formal "oppose" !votes above (as of now, anyway). I don't want to see it get lost again. What do you need in order to move forward? Edits to common.js look like they have to go through MediaWiki talk:Common.js or WP:VPT. Otherwise, is there anything others can do to help? — Rhododendritestalk \\ 12:29, 19 May 2016 (UTC)
i will work on creating a full demo system here. it will probably be made of the script itself (already on enwiki, more than once - one in my userspace, and a second time where another user copied it to WP space for some inexplicable reason). i expect the demo to be comprised of the following parts:
the pgn viewer script in my userspace (~ 27K of non-minified JS)
a small CSS in my userspace
a small "wrapper" script to load the previous two, also in my userspace
a template that accepts order-based parameters, each of which is a game using the PGN notation
a sample page using this template. interested users will be able to try it on any (non article-space) page
an instruction page explaining what need to be done to add the whole shebang to enwiki. to implement the system, a local sysadmin will have to follow the instructions.
to review the demo, one will have to add the wrapper script to their personal js.
i am not 100% confident the demo will work for no-javascript viewers: this may require adding a line to Mediawiki:Noscript.css.
i can't commit to a timetable - i have some other obligations, but i expect this to be done by the end of the week, hopefully earlier. peace - קיפודנחש (aka kipod) (talk) 15:42, 19 May 2016 (UTC)
PGN viewer 1 - demo
ok, so i created the template and the demo.
add to your personal JS page the line importScript('User:קיפודנחש/pgnwrapper.js');
view User:קיפודנחש/pgn viewer demo. (notice the "flicker" when opening the page, where you see the raw PGN before it disappears and replaced by the viewer. this will not happen once all the right pieces are in place).
to test it yourself, create a page and add to it
{{Pgnviewer
| 1 = pgn of game 1
| 2 = pgn of game 2
| ... up to 30 games
}}
and open the page. the viewer is a bit restrictive about comments: comments can't be nested, and should only use { .... }, not ( ... ). if the pgn contains comments, an extra button is added, to hide/reveal the comments.
@Rhododendrites: my bad. i had a typo in the wrapper. i think i did not notice it b/c some old forgotten junk in my personal js script still loaded the script anyway... please try now (you may have to hit "refresh" or something).
however, this incident clearly shows that nobody else tried the demo. i propose that anyone participating in the discussion, will at least indicate whether or not they tried it. peace - קיפודנחש (aka kipod) (talk) 16:33, 20 May 2016 (UTC)
@Rhododendrites: the problem was with the PGN. i restored an older version and fixed the PGN. the problem was with the castling at move 15: the pgn you copied from wikipedia had "0-0" instead of "O-O" (zero instead of the letter O). in general, when something is wrong with the PGN, load the page with "debug=true" in the address line, and look in the JS console: the script squirts out the first difficulty it finds. in this case, it complained about move 20, so it was of limited help. eventually, i downloaded the pgn from one of many places it's available (in this case, here, only b/c it was the first google hit), and compared manually. notice, that in the version i restored, there are tons of comments: when the PGN contains comments, the buttons row grows a new button, "{...}" that lets the reader hide/show the comments. HTH, peace - קיפודנחש (aka kipod) (talk) 00:36, 21 May 2016 (UTC)
Ah! Ok thanks. So as it is, it's kind of cumbersome on the page. Some parameters to control the style of presentation would probably be necessary before incorporating it into pages. The default should probably be to hide everything other than the game board and the controls at the bottom. Given there doesn't look to be a way to use references or wikimarkup in the PGN it'll probably be preferable to keep annotations in the text of an article (or at least hide them by default). The notation is important, but takes up a lot of room that, again, could be integrated more flexibly into the text (maybe?). Maybe this would be a good opportunity to solicit implementation help at WP:VPT. — Rhododendritestalk \\ 01:06, 21 May 2016 (UTC)
PGN viewer 2
I have constructed a rough working outline for a chess game viewer using a great deal less code than kipod's PGN viewer. I've done this because 1000 lines of JavaScript required by the script to understand the rules of chess to decipher the PGN instructions is personally tough to swallow. Although PGN may be a standard, this is Wikipedia on MediaWiki and all we need is an annotated slideshow with certain UX requirements specific to the project. My intention is not to tread on toes or pooh pooh the efforts of kipod; I am just suggesting an alternative before it's too late. I'd have said something earlier, but wasn't expecting the rush to thrust this proposal forward.
I guess the big question for kipod and Fred Gandt is what would be gained/lost.
PGN is very well known in the chess world, which means it would be easy to (a) copy a game from a personal library or existing pgn, (b) export a game found on Wikipedia for use offline (I suppose we're getting into WP:NOT territory if we made that a priority, but would nonetheless be handy as an educational tool), and (c) include metadata and annotations. Template parameters are an obvious substitution for metadata, as it's just fields and values, but I'd be curious about what would be lost. Perhaps it's a matter of taking a ground-up approach to add code/features only as needed? We could also go with a solution that keeps the code light on the page, but have a separate tool with more features that a user can opt to use... thinking too many steps ahead now, I suppose. — Rhododendritestalk \\ 13:40, 20 May 2016 (UTC)
i can't comment on pro/con of Fred Gandt's post, because i have no idea what he is suggesting. his comment "all we need is an annotated slideshow with certain UX requirements specific to the project" is puzzling - i can't imagine what slideshow he refers to, and how the slides in the show will be generated. peace - קיפודנחש (aka kipod) (talk) 19:39, 20 May 2016 (UTC)
PGN viewer 2 code
If you can please just bare with me; I only started this yesterday (as I said, I didn't expect the rush for the finish line), and am working on en passant, castling etc. right now.
The notation I'm using is based on standard notation so it should be easy for those used to it, and essentially easy for those who aren't too.
Due to the typical last little fiddly bits being slightly frustrating, I might not have it finished tonight, but will make every effort to get something that at least offers a substantial hint up for demo. Fred Gandt · talk · contribs01:40, 21 May 2016 (UTC)
In an aim to keep the notation as close to standard as possible, the whole thing is more complex than it practically needs to be - so I'm dragging my feet a bit. Without the notation concerns it'd be half the size and finished!
Here's what I'm working with (so far); it's a HTML file you can copy to a local file and view in your browser. For those who don't know how, there'll be a demo on the wiki soon(ish).
It's unfinished, but shows basically of what I'm doing. The use of Modules and Templates will do a lot of heavy lifting. Please reserve feedback about the actual code; it's a work in progress with all kinds of sloppy and many things to change (planned but not yet executed); I just grabbed what I have and dumped it here unedited. I'll have a fully operational Module driven template includable demo done as soon as I can. Fred Gandt · talk · contribs07:50, 21 May 2016 (UTC)
I've updated the HTML file a few times since first posting, and it's currently nearly fully working. Once en passant is programmed and I've run a few tests and tweaked it to my liking, I'll do the next bit, which is building the Template(s) and Module(s) to wikify it for fully fledged demo.
But as you can see, there's substantially less code, and bar some tweaking after discourse, provides all the functionality we need. Fred Gandt · talk · contribs10:43, 22 May 2016 (UTC)
I couldn't resist updating the HTML code above one last time; it's basically finished, and really cool (even though I do say so myself)
The demo game contains captures, en passant, castling and check, recovery and mate. There are more options for output than demoed, but they'll become clearer with the wikified version. The instructions will be compiled along with the HTML by the Module(s), from editor placed Template calls containing fairly standard game notation.
The code can still be whittled a bit, but that's pretty much what I propose. The Template-Module bit will come ASAP. Time to walk my dog though. Fred Gandt · talk · contribs12:29, 22 May 2016 (UTC)
I find this disruptive. This is the proposal page, not your sandbox. Please find some appropriate place to place any code, templates, modules, and anything else required, set up an appropriate demo, and come back here once it's set up, with insrtuctions how to use it. Until then, please try to minimise the noise on this page. Thanks, peace, קיפודנחש (aka kipod) (talk) 19:06, 22 May 2016 (UTC)
It doesn't bother me. Someone tweaking code on this page is really no different from someone tweaking their comments on this page. WhatamIdoing (talk) 19:59, 22 May 2016 (UTC)
Providing updates of a demonstration (albeit not wikified yet) of a solution to a proposal is completely within the normal scope of this page's purpose. Posting chronologically unnecessary personal complaints about user activity is well outside the scope of this page's purpose and should be done on either this page's or the user's talk page. This comment I am adding now shouldn't be here, but I'm gonna cite WP:MULTI and sleep easy.
While I'm here again (unplanned): I've locked the height to a user setting so it won't make the layout jump about (the width was already user adjustable) and tweaked the code about as much as needed (possibly too far for maintainability), but that will certainly be changed in any review process before it goes anywhere near the common.js. I just have a repeat option to add (so it can be used like a .gif for little things like demonstrating en passant or castling), which shouldn't take long. Then there's all the fun of testing and finding that I did it all wrong and have to start again! ;-)
I underestimated the complexity required of the module, and since I'm just a learner with Lua, it may take a little longer than I initially inferred; sorry, I will endeavour to not keep you waiting too long.
While here, I've updated the HTML again to the last version it'll ever be. From now on, all the work I do to finally make a demo will be done on the wiki. But at least you can play with the HTML demo, while you're waiting, if you like. Fred Gandt · talk · contribs05:47, 24 May 2016 (UTC)
@Fred Gandt: There may be more than one chessboard in an article. As such, having an ID selector for the board is not compliant with HTML 5. You should change that to a class .chessboard or .chess. Probably .chessboard. --Izno (talk) 07:54, 24 May 2016 (UTC)
I might suggest also that your other HTML classes can be vague (".information"? ".black"?)--I would suggest you clean that up as well. --Izno (talk) 07:56, 24 May 2016 (UTC)
@Izno: Yep; as I said ... will need to be edited a little to make them wikisafe. The CSS especially, but there are some vital changes required to the JS to make it work here. The HTML demo is self contained; only the render and rough idea of weight are demonstrated by it. Don't worry; it's all in hand. Fred Gandt · talk · contribs11:03, 24 May 2016 (UTC)
My sincere apologies for delaying this discussion (although of course the discussion can continue without me or the scripty thing I'm building), however, the Lua is almost complete; I just have some rather complex fiddling to do to get the correct notation output. The CSS is effectively done but will require some tweaks. I've tried to make the template(s) as user friendly as possible, including an optional helper template for editors unfamiliar with standard notation. Once the Lua is finished (although it will definitely benefit from serious code review (when I'm done)), I just have the JavaScript to rewrite to work with the wikified markup which will be a quick job.
So although it's all in a constant state of flux right now, the way it's shaping up can be seen in the (also unfinished) documentation of the template. The user script will need to be added to your common or skin JS to see the demos correctly. It offers the opportunity to see what they'd look like if you had JS disabled, by loading the first wave of CSS (which would be delivered to everyone all the time without JS being involved) but not continuing unless you tell it to.
You'll note how editors are provided some visual feedback if the fallback .gif (a possible solution for users with JS disabled) is omitted or invalid in preview mode, and if the fallback is missing or invalid for noscript readers, a message is displayed explaining why they see no demo.
Obviously there will be a lot to discuss, as I'm positive changes will be requested or even insisted upon, but I would prefer to leave that until I have it fully functional please. The actual raw code (not the functionality or aesthetics) will absolutely without question need to be carefully reviewed and altered as necessary before going anywhere near the site-wide common files, so there's little point discussing it. Fred Gandt · talk · contribs02:39, 30 May 2016 (UTC)
Request for Comment: Implementation of interactive chess boards
It is requested that the community comment on the possibility of implementing site wide, JavaScript enabled, interactive chess boards for visual demonstration of described plays. Two example implementations are available for viewing and to aid discussion of the requirements for this proposal.
It will fallback to an animated .gif (if provided) for users with JavaScript disabled.
Both these demonstration examples require the addition of JavaScript to your common JS to see them.
This RfC is to determine if and how such a feature might be woven into the fabric of Wikipedia such that ALL users will see the proposed functionality by default. Although not necessary, it would be helpful to please first view the demonstration examples in their scripted and unscripted conditions before commenting. Be aware that some CSS styling is also required, which is imported by the JavaScripts; the unscripted display may not be exactly as intended in any eventual site wide implementation.
How difficult would it be to generate a fallback animated GIF from the source data if one is not available? Rwessel (talk) 06:28, 6 June 2016 (UTC)
I've been thinking about that myself, and although something may be is (but at what cost?) possible with <canvas>, I think the required code would be unwieldy (and "derp" - requiring JS to generate); it might be possible on the back-end, but I'm not very familiar with the architecture (perhaps tools.wmflabs.org or with an extension?). It would be ideal.Fred Gandt · talk · contribs 11:16, 6 June 2016 (UTC) P.S. Another possibility is to use CSS animation as the fallback, but that would only work on modern browsers and would (without a lot of faffing about) only work when - T483 - proposed dynamic CSS is available.Fred Gandt · talk · contribs 11:26, 6 June 2016 (UTC) P.P.S. This is a job for a bot: It would monitor a category of demos with missing fallbacks, get and parse the instructions, generate the .gif (relatively trivial in PHP) and upload it to commons, then add the link to the demo. Each set of instructions can be hashed and checked against existing .gifs to avoid redundancy, and every .gif would be manufactured to a standard for continuity. This method should be preferred over user uploads, and is effectively ideal.Fred Gandt · talk · contribs 12:09, 6 June 2016 (UTC) P.P.P.S. It's possible that creating the whole bundle as an extension, thus avoiding the need for a bot, is the ideal way to implement. Falling back would be a doddle in that case.Fred Gandt · talk · contribs19:11, 8 June 2016 (UTC)
I'm going to try to start the ball rolling here, by outlining why I chose to write an alternative suggestion to kipod's. At first, my reasoning was simply that 27Kb of JS seemed like a lot of code for something that didn't strike me as requiring that much. I scrolled through his code, and learned why it was so large (relatively); it needs to understand the rules of chess to function, as it has nothing but the PGN notation to go on, and chess notation (either standard algebraic or PGN) contains little disambiguation i.e. only when a human would need it. There's no reason to expect the programming to do all the leg work; we can build the program to accept any input we like and are not limited to using PGN, a language (see below) designed for computers to read and write, not humans. Since most editors on enwiki are English speaking humans, the instructions we supply to any element of any article should be understandable to English speaking humans. It translates that plain English instructions are easier to process than PGN (with some caveats), and so the code size is reduced significantly, whilst the accessibility is increased greatly.
Further to that:
I felt that his interface design (although he's updated it since) was not aesthetically aligned with Wikipedia's usual style.
It's weighted in favour of displaying multiple full games in a single instance, which although handy on a chess blog or forum, seems less than useful here. I think any need we have to display user controllable animated chess moves, is almost invariably going to be for focussed attention to a few details/moves. A page like Ruy Lopez demonstrates perfectly the encyclopedic need for a better way to visually describe moves being made.
It requires special knowledge to implement, or requires copying code from elsewhere. These two issues are IMO major pitfalls; like any other template, infoboxes being ideal for example, the implementation should be simple to understand and require no special language constructs or coding knowledge. Any editor should be able to freely make changes to all parts of every page (unless protected for reasons) without their being expected to learn a new language to do it. PGN and FEN are basically computer languages, designed for programs to read and write. For an editor unfamiliar with these languages, implementing a simple demonstration of a few chess moves would be impossible without first learning how to write that special code. The alternative of requiring editors to copy the required code from somewhere else, is IMO definitely not something we should encourage - for obvious reasons.
Standard algebraic notation, although also being a special language requiring some learning to understand, is used pretty much exclusively in our chess articles, for describing chess theory and/or practice. It's very similar to PGN to read and write, so using it for implementation could be considered not much better, but importantly, it is the standard notation used on practically all the other articles. Where we're showing any chess notation, it should always (except in articles specifically about PGN) be algebraic, and not PGN. I realised though, that expecting editors to be able to write algebraic notation fluently was unacceptable, so I created a template that takes plain English input, and outputs algebraic notation.
For setting up the board in a non standard way i.e. not the way a game is usually started, I opted to use mostly plain English. This is again to make the implementation as simple and accessible for all editors as possible. FEN on the other hand is insensible gibberish unless you've learned it. We can safely assume that editors of enwiki have a reasonable understanding of English after all, but to assume they all read and write FEN is ludicrous. I, for one, do not; and I am not inclined to learn it either.
Stylistically, I consider it vital that the widget (for want of another word) blends into articles, and designed mine to do just that both rendered and raw. The wall of PGN used to fuel kipod's viewer looks out of place in both it's raw and rendered (for users with JavaScript disabled) form IMO. We need to allow editors to position and manipulate the demos to fit into sections and paragraphs in many different ways, and the implementation thus needs to be as similar as possible to how we'd build most other types of common image display or infobox type of thing. I've also focussed on falling back to an animated .gif image for users with JS disabled, rather than outputting what is basically machine code, directly into articles. Although originally I thought to have editors provide the .gifs, I've decided to construct a MediaWiki Extension to do it accurately and consistently as and when needed. This would mean that every instance will have a visually appealing and useful fallback without any editorial effort.
I'd like it to be understood that I am not biased in favour of my own code being used, so much as biased against kipod's. Yes you read that right. This however is not an opinion about kipod - just the PGN viewer.
I am certain that the code I've written for this to date will absolutely need to be rewritten before it goes anywhere near the site's common files. The Module is probably very naive (it's only my fourth ever) and due to the insanity (IMO) of supporting ancient browsers, the CSS and JS will have to be dumbed down. Fundamentally though, other than some fiddling about it won't need to change in functionality that much (except where the community decides that it should). As such, I would argue that my code shouldn't be used. However, no matter how much fiddling about is done to kipod's code, whilst it requires special knowledge or copy/pasting to implement, and outputs machine code into chess articles, and has no suitable fallback, and is focussed on the display of multiple full games instead of smaller simpler demos, it is, without damning it for what it is, not suitable for English Wikipedia.
I will gladly support a better implementation than my own, if it meets or exceeds the requirements as I've attempted to outline them above. And it is these requirements that I think the community needs to carefully discuss here. Fred Gandt · talk · contribs02:36, 10 June 2016 (UTC)
Great work from both developers, much appreciated! My opinion:
Input of a game with dozens of parameters is cumbersome, no matter if you're novice or experienced. Stick to PGN, which also allows embedded comments easily. Input of metadata such as player names and tournament info should be optional. So in Fred's examples, as an editor, I'd like to replace all the |1=|2=… parameters with just |pgn=.
FEN input is very machine-like. While it should be supported for interoperability, I like Fred's natural-language description of a position such as "white king b1, black king e8, white rook d1, black rook e4", however it may get a little verbose for non-trivial positions, so I would suggest shorthand such as "white Kb1 Rd1, black Ke8 Re4", and call it |position= accepting either FEN or the human-readable notation.
Kipod's viewer has a helpful switch between black and white points of view, this needs to be in the production version.
Comments along the game should be visible at each step, not merely highlighted in the notation view (both implementations show the whole game, I think we should show just the current move pair and its comments).
Generating an animated GIF for non-JS browsers is a distraction; let's get the basics working first.
For the examples, I purposefully (perhaps not the best idea it seems (more of a documentation issue that a technical one)) used the fullest longhand setup syntax; setup can be written as "white K e1" or even "white k e1" and can trivially be shortened to "w k e1" if desired, although this starts to become inaccessible gibberish for future editors. Accepting a full English piece name allows a less machine-code-like setup, but I too like to be able to use shorthand when I'm familiar with the application, so included it. Although setting up with FEN might be handy for a particular editor, the markup will remain in the article, and be incomprehensible to others. This IMO opens us up to demos being inaccessible to future editors without special knowledge. Like programming code in a multi developer environment, it needs to be maintainable, by anyone, at any time later, without a need to track down the previous editors to ask what something means or how it works.
I toyed with the idea of also accepting PGN, but decided to focus on a purely Wikipedia oriented syntax, as there are no interoperability issues; we don't need to use code from elsewhere or have code from here work elsewhere. It also leads to the same issue of resulting in something that made sense to the editor that added it, but may not make much sense at all to any future editors. There also is a concern worth consideration, that allowing multiple syntaxes for input, creates incontinuity from article to article. I really think it best to have a single, consistent syntax that is as accessible as possible. Defaulting to natural language may be cumbersome for editors who are comfortable with PGN, but that can still manage; PGN is incomprehensible to everyone else, and editing becomes problematic. I personally find that a numbered param per move is simple to understand and hardly difficult to write, but will give some (more) thought to accepting a natural language alternative requiring fewer params.
In my first few drafts of the demo code I wrote, I had notation and any attached commentary being printed as the associated move was made. I changed this to a permanent display with highlighting after realising how disruptive and distracting the dynamic display was. One major issue is keeping the demos compact, and having them fit into articles in whatever way editors feel is appropriate. In that case, the demo needs (as much as possible) to be a reliable shape and size, without unnecessary empty whitespace. A dynamic display without a fixed aspect large enough to accommodate the largest notation will change size and shape every move. This causes the layout of the article to be altered every move. It's extremely annoying. Further to that, semantically, it's important to have a complete rendering of all the encyclopedic content, all the time. Screen readers and the like depend on a reliable and standard HTML page structure; dynamically altering bits is fine and often great for frivolous websites, but I think not here. As much as possible, the article content should be static and organised. I have included options for formatting the notation output, giving editors some freedom to customise the content as they see fit.
The fallback for users with JS disabled is arguably more important that the scripted demo. If the fallback doesn't work, it's like building a house on jelly; the fallback is the basics. We have to have a strong foundation, or the whole thing falls down. I personally think users of the internet in the second decade of the 21st century should expect the web to be rubbish if they turn off JS, but this isn't some trivial blog; we have a duty to offer useful content to as many people as possible, even if their technology sucks. Falling back to a .gif doesn't actually change any functionality (for me), and is not in any way distracting. I have already started on the code (although I'm not rushing).
i am glad this rfc gets some traffic. i will try to relate to some of the points raised so far, and maybe some new ones.
we can break the discussion into two main areas:
The reader's UX
the editor's interface (i.e., the parameters passed to the "chess viewer template", whichever it is).
i will only relate here to the 2nd point, and for this, i make the following assertion: editors in enwiki who actually edit Chess-related articles, are serious about chess.
i claim that the best way for these editors to feed in chess games to the chess-viewer template is the most familiar notation used by people who are serious about chess. this notation is PGN for actual games, and FEN for initial positions. User:Fred Gandt wrote above: FEN on the other hand is insensible gibberish unless you've learned it. We can safely assume that editors of enwiki have a reasonable understanding of English after all, but to assume they all read and write FEN is ludicrous.. IMO, this statement demonstrate lack of knowledge or lack of understanding. people serious about chess, read and write FEN. this is how people record mid-game board position. every member of Wikipedia:WikiProject Chess, and anyone ever likely to actually write or edit a chess-related article (at least the part related to the game itself), is extremely unlikely to be perplexed by FEN. i would love someone from the actual chess community to weigh in here, and tell me whether this assertion is correct or not, but until someone does, this is my assumption. i believe Gandt that for him it's gibberish, and you may be surprised to hear it's gibberish for me too, but it's *not* gibberish for any serious member of the chess community in enwiki.
as for PGN, i don't even need to assume: chess articles in enwiki are rife with games presented using PGN notation *today*. this is the standard way to show games. for instance, look at the article Deep Blue versus Garry Kasparov: it contains the PGN of all 12 games (6 games each of two matches). the most natural way for any editor, even slightly familiar with chess to feed in a chess game to a game viewer is via the PGN.
moreover: we do not do original research in wikipedia. any game likely to require either of these viewers is some notable historic game, sourced in some book or database. guess what? every single one of those games, appearing in a book, newspaper article, or a database is presented in the form of its PGN. requiring any other format forces the editor to deconstruct the pgn, and translate it to some notation that some developer in wiki invented. this makes zero sense to me.
just to demonstrate this point, i added to my "demo" page all the games from Deep Blue versus Garry Kasparov. i did not take the PGN from one of the dozens of online databases containing them: i copied it from the wiki article itself (with one change - the article shows castling as 0-0 instead of the standard O-O, which i fixed). it took me all of 4 minutes to set up the viewer, again, *from content already existing in the article*. this is sub-optimal (for instance, it's lacking all the metadata routinely found in PGN), and was done mainly to stretch the point: PGN is *not* some "foreign notation meant for computers but not humans". PGN was designed to be consumed by both computers *and* humans, and in fact, it is the standard way we present chess games in enwiki *today*.
@קיפודנחש: (aka kipod): That (Deep Blue versus Garry Kasparov) is not PGN; that's algebraic notation, which is very similar to PGN. The reason you had to convert the castling to the PGN Os from the algebraic 0s is because it's not PGN. And it's not PGN because most chess articles use algebraic notation - not PGN.
this book about "Deep Blue versus Garry Kasparov", chosen without bias from the article's "Further reading", also uses algebraic notation, albeit formatted in tables. That's just one example of how the standard notation may be presented in a non-standard way.
Strictly requiring PGN formatting of algebraic game data is restrictive, and it is exclusive to require that only people who are serious about chess may understand the article content in both its raw and rendered state's.
However, after reading JFG's comments (whilst out walking) I gave some thought to the issue and decided to allow more freedom and options in the setup of demos using my code. I will allow the use of FEN and PGN (I already allow PGN castling notation), but if used as an input, it will be converted to standard algebraic notation for output.
I don't see the point of arguing at length between PGN and algebraic notation: PGN is algebraic notation of the moves + optional game metadata, so any discussions on their relative merits and intuitiveness are moot. For convenience, the code should allow both 0-0 and O-O for castling input, and keep game metadata optional. In this way, no matter where editors copy the game from, it will be valid.
I would strongly advocate against allowing the suggested alternative input syntax in the form of having one template parameter per move; this is both cumbersome and unused anywhere.
I very much doubt that chess amateurs can read/write FEN fluently; I for one can't, even though I'm both a chess amateur and a programming professional; position input requires a human-readable shorthand notation such as the ones suggested by Fred and myself above (but do accept FEN input to allow copying from/to other places)
first, a side: 0-0 vs. O-O: i just taught the script/template to accept either as castling, to reduce the noise in the discussion.
the main point is, the issue is not "pgn vs. algebraic notation", really: it's "pgn/algebraic notation vs. Fred Gandt's template input", or, more broadly, using standard notations and syntax vs. a proprietary one invented for wikipedia. for the first question the difference is clear (i chose arbitrarily the first game in "Deep vs. Kas" - the contrast becomes even starker when choosing a game with 60 or 70 moves instead of 37, such as game 2 in the same series):
it's the same thing about opening position, considering FEN vs. some wiki-invented syntax: note that one of the very first things you see in Wikipedia:WikiProject Chess#Diagrams, annotation and notation is a link to convert FEN to {{Chess diagram}}. this is because when an editor in wikipedia writes a chess related article related to some specific game or position, the FEN is usually available, while some "wikicode" invented by someone in enwiki is usually *not* available, so a "converter" is needed. for instance, any game for Chess960 which is available anywhere on the net, will have the FEN of the opening position. if we require some invented syntax, every editor who wants to use it will have to write the whole shebang manually (and maybe, eventually someone will create a "fen-to-wikipedia-chess-viewer" converter...). we should cut the middleman and simply accept FEN. anyone should take some arbitrary chess960 game and use either of these methods to describe the opening position to get a feel of the issue.
inventing "more english-like" new syntax, because "after all, this is wikipedia", makes as much sense as inventing wiki-specific syntax for mathematical formulas instead of accepting LaTeX, or inventing some wiki-specific syntax for musical notes instead of processing lilypond's notation: sure, LateX and lylipond syntax looks like gibberish to *me*, but mathematicians and physicists use it routinely, and musicians use lilypond's notation, so <math> and <score> tags accept those. similarly, the "language" of chess is pgn/algebraic notation and FEN, and this is what makes most sense for chess-related templates to accept. as an exercise, try to encode the opening position of some Chess960 game using Gandt's notation, and compare to the FEN.
as a side note, just b/c i mentioned "chess960": i realized that my viewer does not handle castling correctly for this variant. this is clearly a bug, but currently it's very low priority for me: nobody ever wanted to use it for chess960 game. if enwiki will decide to adopt the viewer, i guess i'll have to fix this bug. peace - קיפודנחש (aka kipod) (talk) 01:11, 12 June 2016 (UTC)
(later addition): apparently, i did not fully understand Gandt's viewer's limitations, so i posted misinformation in the comparison (collapsed) table above. i fixed it now. in it current state, i think this viewer is not usable - it requires significant amount of work from the editor in order to convert available algebraic notation/pgn to the parameters the viewer requires: each of the parameters represents "half a move", i.e., for move #9 in the algebraic notation, the editor has to add parameters 17 and 18, and add to each of them the the "from" square, which is not available in the notation. Gandt claims he is going to teach his viewer to consume PGN/algebraic notation at some point - once he does this, his viewer may become usable. קיפודנחש (aka kipod) (talk) 13:26, 16 June 2016 (UTC)
Richard L. Peterson is a math editor on Wikipedia, and probable math whizz elsewhere. He and I worked together a couple of times (first time and second time), due to my being relatively comfortable with coding stuff, and him finding it comparatively challenging. I don't speak "math" at all, but he speaks "math" fluently; he found the editing difficult, not the subject. His expertise with maths, didn't help him at all when it came to writing a foreign language. If only someone had written a Wikipedia specific, editor friendly, plain english markup language for compiling equations in maths articles, he wouldn't have needed any help, or had so many challenges.
Templates are entirely wiki-specific markup, and the slight difference between "1.e5" and "|1=e5" should hardly baffle too many chess notation (I'm pretty good at chess, but had never read or written algebraic notation until this proposal popped up) experts. A long string of notation though (especially in PGN formatting with possible optional commentary) might be quite daunting to any but the most familiar with it. Rather than asking for someone from the actual chess community to weigh in we should be asking for feedback from general Wikipedia editors, WikiGnomes and folk like me who bumble about doing all kinds of odd jobs. We're not experts in anything very much (well I'm not anyway), and are often unfamiliar with the article subject(s) (which is often why I'm reading it), and should not be excluded from editing ANY chess article because we're not a serious member of the chess community in enwiki.
What standard I ask you, is the markup used for wiki tables, or infoboxes? It's a wiki standard, plain and simple. Why ask editors to learn an entire other pair of languages in order to edit the English Wikipedia?
As I have already said (BTW: glad to see you've updated your code to accept standard algebraic castling - a wise move), I am adding code to also accept FEN and PGN, so this part of the discussion is effectively moot now. However, I will not be outputting PGN into articles, and will continue to focus on maintaining and developing (as much as possible) a wiki-specific, plain English syntax, since anything and everything developed specifically for enwiki should be entirely wiki-specific, and requiring only the speaking of English.
Serious question: Do you really have anything against editors being enabled to use multiple formats, or is the argument in strong favour of "PGN only" due simply to your code accepting only PGN? Is the idea of making life simple for as many people as possible really so bad? Fred Gandt · talk · contribs03:32, 12 June 2016 (UTC)
Frankly I'm not sure I see the advantage your (Gandt) notation has over PGN. At that point I can see no justification for supporting anything other than PGN. Perhaps an easy simplified-notation-to-PGN template or tool would be of use to editors, but I don't see a justification for the alternate format in articles. Rwessel (talk) 04:07, 12 June 2016 (UTC)
to answer the question ("Do you really have anything against editors being enabled to use multiple formats") first: having options is good. if the template can accept either standard algebraic notation (or PGN), and in addition it can also take some home-brewed other syntax, then it's groovy. if it *forces* the editor to use this home-brewed syntax, then it's not. saying that "the slight difference between "1.e5" and "|1=e5" should hardly baffle" does not make sense to me. wikipedia uses sources, and what available on those sources is algebraic notation of games (or, more precisely, PGN). forcing editors to manually convert the available material to some other syntax you invented because "this is wikipedia", makes no sense.
as a side, i believe your system already uses some non-negligible amount of lua code anyway - why not teach it to consume straight algebraic notation (or better yet - also teach it to consume straight PGN) - this way we can drop this silly discussion and concentrate on the pros and cons of the viewers?
Gandt claims he is "pretty good at chess". i can say the same thing myself, but i never contributed to any chess-related article on wikipedia, and i will be very surprised to hear that Gandt did. i believe that the people who do, are not "pretty good at chess" - they are actually experts. these are the people whose opinion matters: not because they are "experts", but because they are the editors who will actually have to use (as editors) whatever viewer is added, if this will ever happen. this is why i think it makes tons of sense to actually reach out to Wikipedia:WikiProject Chess and solicit the opinion of the people who are the *real* "customers" of this tool from the editor POV.
it also ake sense to reach out to everyone else (representing the "readers") to solicit opinions about the UX, but it seems we are not there yet.
if i understand correctly the angry-red comment above, it means Gandt's script/module/template/demo is not quite finished yet. i am happy to learn that he decided to support the standard notation, in addition to the homebrew input, but i do not know if it's a small change or a huge one, and how much time is required. maybe we should pause this thread until he is done? peace - קיפודנחש (aka kipod) (talk) 03:32, 13 June 2016 (UTC)
Angry? Stop being so combative.
There's no reason to pause the discussion; we need to discuss how the implementation should look, and what styling options are needed/wanted. Also, I've been thinking that it may be best to push the eventual agreed code into an optional Gadget for a while, to get some real user feedback and experience before possibly rolling it out to the default. This would of course means that users without the Gadget enabled would need to see something useful, so the Gadget would act to enhance otherwise stable and encyclopedic content - i.e. replacing current diagrams with potentially Gadget enhanceable alternatives. This should be discussed.
There's no rush (half the reason I started work on another option); we should take this carefully and as slowly as that requires. Apart from any technical or stylistic concerns, the whole idea needs a much wider response that a handful of enthusiasts; it's a big deal trying to add default JS and CSS to enwiki (as it should be), and we have a responsibility to do our best to arrive at a solid, agreeable, technically sound, ..., etc. solution. I wouldn't expect this RfC to be the last on the subject; this is just the beginning. Fred Gandt · talk · contribs03:52, 13 June 2016 (UTC)
regarding "look and feel" feedback: i will be happy to provide some, and even happier to receive some. i asked for criticism/feedback/suggestions several times. as to the appropriate "fallback" - i have an opinion there also, and will be happy to provide it. i do not see need for gadget, as long as there are clear and simple instructions to test either of these demos.
some feedback: (1) it is expected (i.e., any other chess viewer i saw to date supports it) for the user to be able to select specific position/move and switch to it directly, without having to cycle through all the previous moves. traditionally, this is done by clicking on the move in the "notation" pan. (2) when the game is in progress, the current move notation is highlighted. however, the last time i tried your viewer, the highlighted move can be outside the scroll region. it's a reasonable expectation that when this happens, the current move will autoscroll into view. (3), "heavily weighted" aside, the ability to show more than one game in the same viewer is very useful. (4) conditional loading of the code is good. basing the condition on some category is not, and IMO is not acceptable.
this ping did not take either (you didn't actually add the links, just moved them from one place to another). are you done with your viewer? if not, when do you expect to be done? peace - קיפודנחש (aka kipod) (talk) 14:20, 17 June 2016 (UTC)
@קיפודנחש: I was pinged. The addition of the new signature block and new spot on the page caused a ping. (You should review the criteria.) --Izno (talk) 14:25, 17 June 2016 (UTC)
No קיפודנחש I'm not done; and have no ETA or even know exactly what I'm doing (chuckle - I'm doing lots of things in dribs and drabs). This conversation should be about what's needed/wanted and how that should be implemented; who writes what code isn't important; it's what code does what that matters. What I'm doing is developing ideas to provide working examples for discussion, and am currently responding to feedback and several other issues I've noticed along the way. I don't expect to ever have a complete package that is inarguably the exact thing enwiki should use. As I've said before, I wouldn't support my code being added to the MediaWiki common files without major review; I'm just working to present example demonstrations for discussion, and the discussion is not dependant on me or my code. More specifically, I'm working to reduce the JS dramatically by offloading more calculation to the Module, and I still have an extension to build, which will take a lot of development, time and discussion before it has a hope of being used by enwiki (I propose that using the ImageMagick PHP library via a MW extension is the most bestest way to implement a reliable, consistent fallback to something aesthetically and encyclopedically useful). I'm working on accessibility and browser compatibility concerns, and with that in mind redesigning the HTML, CSS and JS... I'm doing lots of things, and have no idea how long any of it will take. Fred Gandt · talk · contribs15:43, 17 June 2016 (UTC)
i don't think the discussion should be about what needed/required and how it should be implemented. i think the discussion should be about one simple question: "should the existing viewer be added to enwiki?"
if we decide _not_ to use it, then whenever you feel comfortable with your viewer, you can open another proposal to add it. if the decision is to use it, then, whenever you wish, you can propose to replace the viewer with something better. if anyone wants to make suggestions for possible improvements, they can make them, before or after the viewer is added, and those suggestions will be implemented or not. this proposal (with quite a few "support", and not a single "oppose") have been in limbo since you announced you can do better. as it is now, i don't think your viewer in its current state is usable. suggesting that this needs to be designed and implemented, is ignoring the fact that we are talking about an existing, mature viewer that's already "in production" on another wiki for more than 3 years, with no reported issues. all we need to do is make a simple decision: whether or not to use it.
as a side: you seem to take it as a given that doing the work (i.e., analyzing the PGN) on the server using LUA rather than on the browser using JS is "better", even though some JS is still required for the viewer itself. can you justify this claim by some rational argument? *why* is it better to "offload" the readers browsers and make wikimedia servers do the work? the only argument i saw so far is "because 1000 lines of JavaScript required by the script to understand the rules of chess to decipher the PGN instructions is personally tough to swallow.". this can't be considered a rational argument: first, the script is actually 854 lines, not 1000. it weighs about 11K 15K minified (versus 3K minified for yours), 11K 15K that the browser gladly caches. second, nobody asked you to personally swallow those lines. third, using your scheme seems to actually inflate the HTML itself by 1-3K per game (the difference between "algebraic notation"/PGN, and "Gandt's notation" which the module, once you write it, will add to the HTML), so even without caching, the "gain" might actually be negative once an article contains more than 3-4 games (in hewiki, some articles using the viewer display dozens of games), and last, but not least: offloading the server and letting the browser do as much of the work as possible seems to be the direction everyone else in the world is going. peace - קיפודנחש (aka kipod) (talk) 21:22, 17 June 2016 (UTC)
thanks. if i understand this comment correctly, it means that Gandt practically stopped working on his viewer, and has no intention to resume the work. this simplifies the decision, i guess. hopefully, the proposal is not damaged to such an extent that it's completely dead. קיפודנחש (aka kipod) (talk) 23:44, 17 June 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Try #2: File:Barbra Streisand - 1966.jpg ... good to go?
New category and articles proposal for 108 martyrs of world war ii, anyone who knows Polish please come forward
Hello, everybody. There is a category on the Polish wikipedia called Kategoria:108 błogosławionych polskich męczenników z okresu II wojny światowej. It is about the Polish 108 Martyrs of World War II. It is not in any other wiki but it appears to be extremely important. I have created a few articles about them but since I don't read Polish I can only create basic information. All of the martyrs have an article in the Polish wiki. If anyone reads Polish, please help to create English articles for those who don't have one. Thank you.
Zee money (talk) 08:35, 30 June 2016 (UTC)
Possible upcoming change of the "Save Page" button
Please see the VPT link above regarding a change that is being made by WMF for the "Save" buttons - and how or if we want this to appear here on enwiki. Thank you, — xaosfluxTalk20:03, 2 July 2016 (UTC)
Done
Thank you --Redrose64 (talk) 19:16, 26 May 2016 (UTC)
Done The updated code for this went live at 
Bumping thread for 30 days. 
