Could an interface admin please handle the request at MediaWiki talk:Mobile.css? Thanks.
Project:Village Pump
About this board
This page is only for discussing issues related to MediaWiki.org site.
Archives
|
|---|
|
|
A minor request. The external link in this section of page Extension:FontAwesome still links to the older version (v5). Please update it as normal users are apparently unable to edit an external link.
There's a thread on the English Wikipedia's Village Pump that would be of interest to MediaWiki devs. As you can see, once the idea is brought up, a large fraction of editors believe being able to mark edits as minor is a bad idea and should be removed. (Disclaimer: I am not a neutral party and am one of the biggest proponents of this idea.) Jason Quinn (talk) 08:52, 28 August 2023 (UTC)
Proper link for convenience: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)#Proposal_to_remove_%22rearrangement_of_text%22_from_definition_of_minor_edit.
That's mostly just en.wp's business. They tell us what they want and we go do it. We already have support in mediawiki for restricting who can make minor edits on a per usergroup basis.
Perhaps devs should question the raison d'etre of the "minor edit" toggle. The claim being discussed is that it is an anti-feature because it does not reliably convey the information it is intended to convey and that this is largely because the concept a "minor edit" itself is ambiguous to the point of being partly useless. The same will be true for all languages. Therefore it should be totally turned off for all languages going forward, not just the English Wikipedia because that community wanted it but because is a bad software design idea (ie this perhaps is more of a development topic than a community issue).
I don't know Mediawiki's codebase but if it's possible maybe all traces of "minor edit" code could be removed completely. That code could be split off into some sort of plugin or patch that enables it if installed. The patch should also have a toggle to have the feature actually turned on or not on the wiki. This approach covers all bases: it excises the minor edit feature from brand new wikis while allowing wikis that want "minor edits" for some reason to still have it whilst also satisfying legacy wikis that don't want "minor edits" but that regrettably need to have it (eg so that past conversations regarding edits that mentioned their minor edit status still makes sense).
Get an rfc on meta if you want it killed across all projects. En.wp certainly doesn't speak for the rest of wikimedia.
As far as if it is a good idea. Meh, wouldn't be the first time mediawiki had a feature that turned out to be a bad idea. Maybe it would get removed if it became clear everyone hates it across the board, but we are nowhere near that stage yet.
In terms of pure practicality - extensifying it might be difficult in its current form. It currently involves extra fields in the revision and recentchanges tables, which is something extensions aren't supposed to do. Probably the way to extensify it would be to reimplement it as a special purpose edit tag. Honestly that sounds like quite a bit of work that's not worth it. If enough people like it we would probably just keep it with an off switch, if nobody wants it it would probably just be removed. (To be clear, i dont speak for other devs or the WMF, they may disagree with me)
More specifically, this would be "complete restriction of…", we won't drop the functionality, just who can use it.
Hello all,
I am pleased to share the next step in the Universal Code of Conduct work. The Universal Code of Conduct Coordinating Committee (U4C) draft charter is now ready for your review.
The Enforcement Guidelines require a Building Committee form to draft a charter that outlines procedures and details for a global committee to be called the Universal Code of Conduct Coordinating Committee (U4C). Over the past few months, the U4C Building Committee worked together as a group to discuss and draft the U4C charter. The U4C Building Committee welcomes feedback about the draft charter now through 22 September 2023. After that date, the U4C Building Committee will revise the charter as needed and a community vote will open shortly afterward.
Join the conversation during the conversation hours or on Meta-wiki.
Best,
RamzyM (WMF), on behalf of the U4C Building Committee, 15:34, 28 August 2023 (UTC)
can you make my page unprotected
https://www.mediawiki.org/wiki/API:Allredirects
The doc on that page could use a lot of additional leading "target-"(redirect) edits in my view. To potentially eradicate the ambiguity that this call might potentially be used to only list source redirects. Which it can't/don't.
:-/
Sorry, but I don't understand what's your request and what do you mean with "target-"(redirect).
Would you like to elaborate?
While writing my initial reply I realized that apart from there being:
A) pages that contain a redirect statement.
B) pages that are targeted by a page containing a redirect statement.
One also has:
C) pages that link to pages that containing a redirect statement.
(ergo: Case A can be seen as source or target depending on your mindset.)
This last one(C) trows a wrench in my thinking (and initial reply).
As I'm now completely lost about which cases (A,B, or potentially C) the API:Allredirects doc might be talking about when its using the words "redirect"/"redirecting" or source" vs "target".
Sorry if this is of no help.
(local minor-headache not helping either :-/ )
This api returns the redirect target (case B)
Ok ...
But is the first line on the API:Allredirects page "List all redirects to a namespace" not highly ambiguous in this respects ?
In my view it seems easily misread in that Allredirects is targeting/returning A-cases(source?) instead of B-cases(target?).
The additional arunique parameter text "When used as a generator, yields target pages instead of source pages." seems to suggest the same (if one ignores the potential C-case).
I know its a fine line for doc's between being concise and being to-concise. The Allredirects page seems to me to be way to-concise on its "redirect" parts. (especially in one takes the C-case in account)
Thinking about the Allredirects page is giving me a headache again. ... So I'll leaf it at that.
Okay, I've edited the page to hopefully make it more clearer. Feel free to improve it. However, most of the page is autogenerated by the api help itself, which would require code changes to improve the documentation.
Actually, A, B and C are "correct". Redirects are a tuple of redirect source and redirect target, and this api is supposed to return that list, but not always. It depends on the parameters. The title refers to the redirect target, but if you make it return the ids, those ids refer to the redirect source.
The best way to see how it works is by testing the api itself.
If you check Special:WhatLinksHere for Project:About, listing only redirects, you get currently 13 results.
The same results you can get using the api with from and to = About, and namespace Project (not very useful output), and the same as generator (the output is the same but titles reflect redirect source instead of target).
Note how "About" in the filters doesn't include the Project: namespace, because it's included in the namespace filter. Adding the namespace manually on the title filters will result in an error (!)
But this usage is not very useful, because that's what API:Redirects returns. The only usefulness of this api IMHO is using it as generator, with "from" and "to" pointing to the same page (a bit awkward), or setting the "unique" parameter.
Thanks at least for the API:Allredirects page edit, and additional information here.
Not sure when I will delve back into Allredirects again though. For the moment my redirection-related thoughts are still too jumbled up for that.
In https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual, the [Section about Federated SPARQL Queries](https://www.mediawiki.org/w/index.php?title=Wikidata_Query_Service/User_Manual&action=edit§ion=16) contains links to foreign sites. By definition, federated links are external.
I cannot update a certain link , I need to change
BIND(uri(concat("http://data.cervantesvirtual.com/person/", ?id)) as ?bvmcID)
to
BIND(uri(concat("https://data.cervantesvirtual.com/person/", ?id)) as ?bvmcID)
to make the query work again
Done
Changing an existing HTTP URL to HTTPS is a trivial change and quite unlikely to be a spam attempt. Couldn’t the abuse filter (I assume Driller001 was stopped by the abuse filter) be changed to allow such edits?
Could an interface admin please handle the edit request at MediaWiki_talk:Gadget-UTCLiveClock.js? Thanks.
Bawolff, could you take a look into this please?
Hi! For some time now, I've been slowly developing c:Help:TemplateScripts, a method for extending the functionality of templates with JavaScript. For obvious reasons, template scripts must be located at the MediaWiki namespace (and have the "TemplateScript-" prefix, see the code below) so they require community consensus and an authorized user to get there. Template scripts are currently available at the Spanish Wikipedia, Commons, and the Spanish and English Wikiversity. I'd like to propose enabling them here at MediaWiki.org too, for the following reasons:
- I'd like to turn the Synchronizer tool into a template script so that it loads automatically.
- I'd like to migrate and centralize here at MediaWiki.org the existing template scripts and documentation, per being more adequate than Commons.
- To attract more interest and developers, since MediaWiki.org is probably the most technically oriented of the Wikimedia wikis.
To enable TemplateScripts, the following code should be added to MediaWiki:Common.js and MediaWiki:Mobile.js:
// TemplateScripts are JavaScript scripts that extend the functionality of templates
var templatescripts = [];
$( '[data-templatescript]' ).each( function () {
var script = $( this ).data( 'templatescript' );
if ( script && !templatescripts.includes( script ) && /^[^&<>=%#]*\.js$/.test( script ) ) {
templatescripts.push( script );
script = encodeURIComponent( script );
mw.loader.load( '/wiki/MediaWiki:TemplateScript-' + script + '?action=raw&ctype=text/javascript' );
}
} );
Thoughts? Support? Objections? Cheers! Sophivorus (talk) 01:27, 12 July 2023 (UTC)
I’d like to rather have an official solution, e.g. phab:T241524. I’m not strongly opposed to using this script in the meantime, but I have the feeling that the more temporary solutions we have, the less likely is that someone takes the time and effort to create an official one.
By the way, I couldn’t find traces of this on Commons except for the help page, are you sure it works there?
Hi! You're right, it's not enabled in Commons (I think at some point it was). As to an official solution, I'd love to see one too! However, that may still require several years (or never come to be, like with global modules and now graphs). Also, by the looks of it, migrating from TemplateScripts to an official solution with a parser function that loads gadgets (as suggested by phab:T241524) seems rather easy. Finally, enabling and developing TemplateScripts now may actually help an official solution come about, by building a small community of involved developers and giving WMF developers some real world examples of its potential. Cheers!
If you want to pave the path for the official solution (and also in order to make template scripts more efficient by taking advantage of minifying), it’d be helpful if TemplateScript was also based on gadgets rather than random JS pages:
$( '[data-templatescript]' ).each( function () {
var script = $( this ).data( 'templatescript' );
if ( script ) {
mw.loader.load( 'ext.gadget.templatescript.' + script );
}
} );
Also, to make it compatible with VisualEditor, live preview etc., it should use the wikipage.content hook:
mw.hook( 'wikipage.content' ).add( function ( $content ) {
$content.find( '[data-templatescript]' ).each( function () {
var script = $( this ).data( 'templatescript' );
if ( script ) {
mw.loader.load( 'ext.gadget.templatescript.' + script );
}
} );
} );
(This doesn’t unload no longer necessary template scripts, but at least loads those that become necessary after the initial page load.)
Excellent ideas! I just implemented them at the Spanish Wikiversity to test them out, see es:v:Special:Gadgets, es:v:MediaWiki:Common.js and the [add objection] buttons at es:v:Wikidebate/Cannabis for the end result. I'll implement them at the English Wikiversity and Spanish Wikipedia soon, if no issues, concerns or further changes follow. These are exactly the kind of ideas for which I think bringing TemplateScripts to MediaWiki.org is the way to go.
@Legoktm @Bawolff @Pppery @Shirayuki @Ciencia Al Poder As some of the most active users here at the Village Pump, may I ask for your thoughts, objections or support on this? Kind regards,
Not involved enough here to have an opinion, so if nobody else objects then feel free to go ahead.
No objections.
I'd prefer using tracking categories for those templates. However, category information in JavaScript is missing from Minerva due to phab:T206337, and it's going to be removed from core too (phab:T206250), which means we're left with using inefficient DOM searches...