Wikinews:Water cooler/technical/archives/2018/July

Special:LintErrors

You will want to fix those errors, especially marked "High priority" can make articles and pages completely unreadable, for example Special:Diff/prev/4418002 (See Special:Permalink/463950 to see what's going wrong - you can't miss it). — revi^☏ 09:51, 3 July 2018 (UTC)

@-revi: I wasn't familiar with that special page; it's interesting. Is there any documentation that explains what those things actually mean? (Without which they are not at all actionable by us; I've got, for example, no freaking clue what that "high priority" thing is that reports over eleven thousand errors.) [I'll try to suppress remark on my opinion of the Foundation's attitudes and policies.] --Pi zero (talk) 12:56, 3 July 2018 (UTC)

mw:Parsing/Replacing Tidy/FAQ#What will editors need to do? explains everything. High priority - I guess that is "things will show as broken if you don't fix it". For example, 2007 Rugby World Cup: South Africa, Australia and New Zealand qualify is causing "Pages using invalid self-closed HTML tags" because <span id="South Africa"/>. It should be <span id="South Africa"></span>. — revi^☏ 13:03, 3 July 2018 (UTC)

I don't know if it will appear broken or not, but there are some self closing tags in HTML -- I still don't know the reason behind that horrible decision, but if I recall corectly, AWB had a pre-defined edit setting to fix it.
•–• 13:52, 3 July 2018 (UTC)

HTML was, in its day, written and read by human beings. It got spoiled by intrusion of arbitrarily fussy technical details that basically forced it to become a primarily machine-generated, and therefore machine-read, language; wiki markup was, in my perspective on history, the perfected form of what HTML had tried to be and failed. (Which is why I find it so mind-boggling and appalling that the Foundation clearly doesn't understand the crucial role of wiki markup in allowing the sisterhood to exist.) --Pi zero (talk) 13:58, 3 July 2018 (UTC)

Custom CSS and JS

Hello,

The withCSS and withJS feature appears to be disabled at this wiki. While there is "perpage css/js code. Includes MediaWiki:common.css/PAGENAME and MediaWiki:common.js/PAGENAME" at MediaWiki:Common.js, it appears to be not sufficient for my needs: I would like to be able to apply custom CSS and JS to the edit intro of an article whose title is specified by the user, and whose page name is unknown (such as from User:Gryllida/NewArticle).

This would allow me to write an Open Search Plugin (a search engine file for Firefox or Chromium) into which I type the article title and I am dropped into an article creation box with the relevant loaded edit intro, CSS, and JS. It would make it easier to write articles for me, and possibly also for others. Another URI could be created for reviewing, with edit intro and css and js that is relevant for reviewing activities. An example URI would be (with XXX specified by user):

http://en.wikinews.org/wiki/XXX?editintro=User:Gryllida/reviewing/editintro&withCSS=User:Gryllida/reviewing/style.css&withJS=User:Gryllida/reviewing/style.js

Is there a particular reason which would prevent withCSS and withJS from being enabled here? If there is such a reason, it would be nice to know of a workaround that would allow to complete this task.

Thank you in advance!

--Gryllida (talk) 01:00, 5 July 2018 (UTC)

I was advised that for security reasons you can only source JS/CSS in the MediaWiki namespace. Is it OK to use MediaWiki:Gryllida/NewArticle/* space for this tool? --Gryllida (talk) 04:58, 5 July 2018 (UTC)

It is also possible that we need to add the withCSS and withJS snippet to MediaWiki:common.js; it is absent there. Gryllida (talk) 22:11, 5 July 2018 (UTC)

I don't understand why we would need these things. I've been putting a lot of effort into providing additional interactivity safely; it seems to me highly desirable to accomplish things within those bounds if possible, and I might be able to suggest how to do that if I understood what was meant to be accomplished. --Pi zero (talk) 22:39, 5 July 2018 (UTC)

I got away with using the existing tabber code: User:Gryllida/NewArticle/editintro (the same as what is used in {{howdy}}.) Wanted to add instant save (workaround: click save and then go back) and sources fill, and the latter can be moved to an external tool with an api (but even then I have trouble imagining how dialog tools would accomplish it). Gryllida (talk) 23:07, 5 July 2018 (UTC)

For the record, I imagine that such a script could be added as a gadget, but the advantage of being able to load a script on-demand by an URL is that a person does not need to log in to enable it. --Gryllida (talk) 23:09, 5 July 2018 (UTC)

┌────────────────┘

Although the dialog tools are currently only able to take input from, and send data to, dialog input fields, I have paused to reflect from time to time that it would be nice to be able to send data from dialog to an edit window and vice versa. One could then write a button that would snarf the contents of the edit window, save it, and return to the edit window. The dialog interface would presumably use reserved dialog parameters; the underlying implementation would require an understanding of the internals of the edit window, which I don't have atm (but perhaps you do).

I really do need to do a better job of technical documentation for the dialog tools. --Pi zero (talk) 23:24, 5 July 2018 (UTC)

• Yeah, since there is a JavaScript code which turns an URL into a {{source}}, it would be nice to implement it in wiki markup. :-)

It could do this URL by URL, without interacting with the edit box..?

However there is a second difficulty: the need to wait for an API call to complete before proceeding to the next step. I am not sure whether the dialog tools are able to do that. (If they were, then User:Gryllida/js/processWLinks-0.1.js could be written in dialog tools also; it edits the page, not necessarily within the edit box, and makes API calls to check for the existence of categories.)

Strictly speaking, documentation is needed, however it may be mimicked with small (byte size so to speak -- really tiny) working examples. If the dialog tools page had a section called 'examples' at the end, with examples of snippets in markup plus the underlying javascripts for each, it could be a small initial version of documentation for this.

--Gryllida (talk) 23:52, 5 July 2018 (UTC)

@Gryllida: A javascript file made to work with dialog is an action. Primary documentation for the dialog tools is Help:Dialog, and the last section there is about how to add new actions; that section in turn refers to page MediaWiki talk:Dialog/receive. There are really three actions implemented although almost everything uses action do; one of those is purely a demo. (There's a category of all actions, which is referenced at Help:Dialog at the top of the section on actions.) --Pi zero (talk) 22:25, 7 July 2018 (UTC)

Re-scheduled deployment of the New Filters on Watchlist

There was a recent announcement about the plans to graduate the New Filters for Edit Review out of beta for this Wiki. The deployment was stalled to fix the performance issue related to the change. The performance of the new interface has been improved significantly as an outcome of the work by the developers [1]. So, the deployment has been re-scheduled. The deployment is scheduled for this wiki on July 9th 2018, 18:00-19:00 UTC.

Please let us know of any other issues or special incompatibility that you may face so that we could make sure they are solved before the feature gets deployed. -- Kaartic (talk) 20:16, 7 July 2018 (UTC)

Consultation on the creation of a separate user group for editing sitewide CSS/JS

(Please help translate to your language)

Hi all,

I'm preparing a change in who can edit sitewide CSS/JS pages. (These are pages like MediaWiki:Common.css and MediaWiki:Vector.js which are executed in the browser of all readers and editors.) Currently all administrators are able to edit these pages, which poses a serious and unnecessary security risk. Soon, a dedicated, smaller user group will take over this task. Your community will be able to decide who belongs in this group, so this should mean very little change for you. You can find out more and provide feedback at the consultation page on Meta. If you are involved in maintaining CSS/JS code, or policymaking around adminship requests, please give it a look!

Thanks!
Tgr (talk) 10:50, 9 July 2018 (UTC) (via global message delivery)

One is promoted to the admin rights after they have gained the trust of not messing up purposefully. And as far as the "serious" risk is involved, anyone can make a mistake. I fail to see any good reason to make another separate user group, especially for smaller wikis, with a lesser number of admins. It would allow non-admins to edit it, yes, and that could be helpful; but the notion that it brings unnecessary risks, it can happen anytime, anywhere with anyone; and that is why one should first try on test wikis like test.wikipedia.org. I hope this is an opt-in for projects.
•–• 16:14, 9 July 2018 (UTC)

@Tgr, Acagastya: I agree. There's no good reason for it, and it'll (not to put too fine a point on it) gum of the works by making community assignment of trust gratuitously more complicated. --Pi zero (talk) 16:36, 9 July 2018 (UTC)

Added a question here. Gryllida (talk) 01:52, 12 July 2018 (UTC)

The new York city of the new York city of the new York city of the new York city of the know should probably

Vbns nee nsnsns have any attachments if the way you know how to get back on Tue Nov and the last time in the new Jersey USA today I am a few minutes of the new Jersey city of the last time to the new York city on Wed Mar to see if you have any questions please send me and we have been very much and we have been very much and we have been in your browser to get it would you can you are you are you are a few months ago when we have a new Jersey USA and I will have any attachments are a bit about —The preceding unsigned comment was added by عـَـاطـٍِف الفـَـاضـِلي (talk • contribs)

Okay, thanks for letting us know. —Justin (koavf)❤T☮C☺M☯ 22:27, 16 July 2018 (UTC)