In T265132#6539501, @Jdlrobson wrote:

You can always create a wrapper function in MediaWiki:Common.js or local to your script for readability.

function loadScript( title ) {
  mw.loader.load( '/w/index.php?title=' + title + '&action=raw&ctype=text/javascript' );
}
loadScript('User:jdlrobson/script.js')

@Jdlrobson Thanks for the info. I'm afraid this means there is no way (that isn't deprecated) to load a userscript without the "ugly" index.php URL?

In T85838#955840, @Tgr wrote:

This would require adding a new thumbnail parameter to generate "frozen" thumbnails for animgifs, and some way to switch between normal and "frozen" thumbnails.

I wonder what are the reasons for page authors to use animated gifs instead of videos, which seems like a more appropriate technology. Is it just that videos are harder to work with (in which case maybe we should offer automated conversion) or browser compatibility concerns or concerns about the video player UI, or do they actually want the animations to autoplay and loop?

In T263211#6473633, @Aklapper wrote:

Removing project team tag as it is up to teams to decide what they plan to work on.

In T256527#6464360, @MusikAnimal wrote:

In T256527#6457759, @MarcoSwart wrote:

@MusikAnimal : It is now nearly two months since you moved this task to "Needs Review/Feedback". Nothing seems to happen. What's wrong?

Hi Marco! Let me first apologize for the long wait. We have been exhausted with higher priority work over the past few months. The bigger issue here is the developer who wrote the bot is no longer on our team, and the rest of us aren't very familiar with the codebase or Python. That said, I have finally merged the change, and it should in theory be running on nl.wiktionary. However this bot task hasn't ran at all (on any wiki) for about a week. This seems to be historically true, where it will run for several days in a row then sleep for a week or so. I haven't quite figured out the logic yet, or if that's just circumstance. So, I guess bear with us while we try to figure this out. We'll be keeping an eye on https://nl.wiktionary.org/wiki/Speciaal:Bijdragen/Community_Tech_bot

In T252814#6474886, @Urbanecm wrote:

I still think this should be WONTFIX/declined: I recently used the group at el.wikinews (https://el.wikinews.org/wiki/%CE%95%CE%B9%CE%B4%CE%B9%CE%BA%CF%8C:%CE%9C%CE%B7%CF%84%CF%81%CF%8E%CE%BF/rights), and I'm pretty sure it's also used somewhere else. It is rare, but still used. This can be also useful even after the userrights issue would be fixed: private wikis don't have global rights applied, yet rarely steward intervention would be required at some custom group, or to do bigdeletes.

In T27471#6296992, @Ammarpad wrote:

I will finish and put this for review after the branch cut.

In T101236#3037332, @Johan wrote:

I think this is a bigger issue for e.g. Tech News than one would first assume.

We have a couple of items that are specifically designed to be exactly the same every week, to make it easier for the translators – they are more complicated the first time you translate them, because you might need to figure out how to best represent dates in your language, but it will save time and effort in the long run. Or so goes the theory. But if they don't, then you have complicated items where you either have to go back to another issue and copy and paste

In T68606#683872, @Tgr wrote:

That said, it won't look particularly good (something like "Mathew Brady Restoration: Adam Cuerden"). That's the limitation of how much meaning can be extracted from templates currently; Wikidata will provide nicer ways.

@kaldari I already gave the solution to that:

Is there another image file format that supports layers?

When I encountered this error (T260272) I thought "oh my, Wikimedia is being DDOSed". When I realized that thumbnail generation for other files still worked fine, I was certain the errror was a bug.

In T255334#6367068, @Tacsipacsi wrote:

In T255334#6366374, @AlexisJazz wrote:

Required a dummy edit.

Actually, dummy edits are no longer needed, even when this bug happens. Since T256868 (6959a02 to be exact), pages can be marked for translation twice (or however many times you want) without dummy edits in between. Just go to Special:PageTranslation, find the page and press mark for translation → Mark this version for translation. In my experience, this always works around the bug just like if there was a dummy edit.

In T255334#6344400, @Nikerabbit wrote:

Meta should get latest proposed fix tonight with 1.36.0-wmf.2. After the deployment, I would appreciate feedback whether it changes anything.

In T91154#6337119, @Legoktm wrote:

In T91154#6335891, @AlexisJazz wrote:

Can you and/or @cscott consider the upgrade script for non-WMF wikis?

We never created any such script for {{!}}, we just mentioned in it the release notes. I agree that it would be good to have but I wouldn't consider it a blocker.

1. Link fixed at 14:51: https://meta.wikimedia.org/w/index.php?title=Tech/News/2020/31&diff=20308410&oldid=20308327
2. Item removed at 14:59: https://meta.wikimedia.org/w/index.php?title=Tech/News/2020/31&diff=20308428&oldid=20308410
3. Marked for translation at 16:16: https://meta.wikimedia.org/w/index.php?title=Special:Log&page=Tech%2FNews%2F2020%2F31
4. Fuzzybot's edit at 16:16 that doesn't fix the link or remove the item: https://meta.wikimedia.org/w/index.php?title=Tech/News/2020/31/nl&diff=20308703&oldid=20308551
5. General confusion

In T91154#6328399, @ssastry wrote:

We've discussed this on the parsing team and @cscott will chime in more, but just to get this out early while you are all discussing this here and other forums, we definitely will not support wiki-specific configuration for a parser function. So, that means: if you want {{=}} as a parser function, all wikis will get it. There will not be an option to opt out.

In T211243#5453828, @Esanders wrote:

1. The 'Edit' action is usually flagged as progressive, so would be blue text, but here I have manually switched it so the 'Add a citation' is blue and so slightly more prominent. We have used this pattern elsewhere when we have multiple actions in contexts. We may want to consider using the 'primary' flag, which makes buttons white-text-on-blue, but that would be a wider change. We could also swap the locations of the buttons, but that may be more confusing and have text length issues (see 2.)
2. Perhaps, I'm a little worried about using long messages here though - I imagine "Citation needed" and "Edit template" won't fit on one line in German

@Quiddity so you can include/exclude translations from MassMessages? Is there a video or bunch of screenshots to show what sending a MassMessage goes like? (I found only 6 screenshots on Commons, most of them similar to each other)

This message from MelbourneStar confirmed my theory: "That's very strange indeed. But yes, you are correct. I got an edit conflict saying that an identical revision had already been made (yours)."

In T138332#2397387, @Mbch331 wrote:

This is a know issue and is handled in T54971. Problem is that https://wikisource.org is a multilingual version of Wikisource and can't be handled easily in the current code. See also https://www.wikidata.org/wiki/Wikidata:Wikisource/Development. I think @Lydia_Pintscher could tell more about this.

This has been open for 4 years.

In T236892#6301847, @Keegan wrote:

In T236892#6301702, @AlexisJazz wrote:

@Keegan @MarkTraceur Can you provide a query for cirrus search to find affected articles?

I think this works:

all: insource:"<graph>" insource:/"<graph>"/

Found at T211881#5065149

The review in that comment is fairly informative from an enwiki standpoint, which shows its usage is limited in the article space and is mainly propagated through a few templates and talk page usage.

A preliminary look at the other wikis (~10) that use the graph tag finds similar results.

@Keegan @MarkTraceur Can you provide a query for cirrus search to find affected articles?

In T91154#6298699, @Base wrote:

If what we come up with is an opt-outable parser function, then I do not have enough experience to do it, please pick this up, someone. (I am open to be taught too :) )

In T205347#4612837, @Jdforrester-WMF wrote:

So, in thinking about this, I'm a little worried on how to get it done. We'll need to:

• Get the rights sorted – T205350
  • Create a new user group for people allowed to edit content
  • Apply it to accounts we want.
  • Adjust edit rights so that * cannot edit or create in Main/Proj/Templ/Cat/… namespaces
• Clean up for SUL
  • Rename local accounts to match their SUL equivalents
  • Rename any conflicting local accounts to something else
• Enable SUL
  • Unify local accounts with their SUL equivalents
• More cleanup?

I figured not allowing account creation was a political decision, possibly as an order from the WMF. If it's just technical, enabling SUL is a better solution.

@MarkTraceur I can't reproduce it anymore either. @Krinkle and @Esanders have recently made a change to mediawiki.jqueryMsg.js, maybe one of those fixed it.

In T246879#6287012, @Etonkovidova wrote:

Checked in betalabs (I do not have sufficient user rights for testing deletion in production)

• deleted a file
• attempted to re-upload the same file
• got the following error message which is different from the task's screenshot (the error message still needs some improvements).

Is there a different error message in production or the steps (delete/re-upload) should be different?

I think I have it.

The message does get parsed outside of UploadWizard though: test on beta Commons.
This may be something:

mediawiki.jqueryMsg: file-deleted-duplicate: Unknown operation "urlencode"

Setting the status back to stalled as that is the status that DannyS712 has assigned. Note that @94rain and North8000 replied in the thread on meta and appear to be in favor of this idea. Also, there is no need for consensus to implement this as a feature. Consensus would only be required to add the new right to any user group. It is true though that developer time is slightly more likely to be freed for a feature for which there is already consensus to enable it somewhere. This is a chicken-and-egg problem though, it would be difficult to garner support for using a feature that doesn't exist yet.

In T256688#6283377, @MrJaroslavik wrote:

I don't see any consensus, so the change cannot be done.

In T236892#6186035, @Keegan wrote:

In T236892#6185989, @Pelagic wrote:

Agree with AlexisJazz, about need for more explanation. How is client-side JS more maintainable than server-side?

Client-side rendering is handled through the browser, and for an individual the cost is very, very low because you're only rending for yourself; CPU usage is a fraction of a percent, there's straight up no danger to individuals.

Scale this up to having the server handling all the requests all the time, and it's the central rendering place that's in danger falling over. It's reached an unsustainable point.

In T71386#6279622, @Krinkle wrote:

In T71386#6279508, @AlexisJazz wrote:

In T71386#735153, @Krinkle wrote:

This is somewhat incorrect. Though andSelf is indeed deprecated, there are no plans by jQuery to remove it. It isn't part of the rest of jQuery Migrate and was not removed in jQuery core 1.8. In fact it still exists in the latest jQuery 1.11 and jQuery 2.x and thus jQuery UI continues to use it so that they don't have to feature-test andSelf/addBack for old versions.

It has been removed alright.

We still have andSelf() defined in the latest jQuery, courtesy of jQuery Migrate providing the neccecary compatibility alias.

Regardless of this, jQuery UI has been updated years ago not to use the deprecated methods see Git/jquery.ui/PATCHES.

I'm declining this for now as indeed we will not be upgrading jQuery UI. At this point jQuery UI 1.9 and 1.12 (latest, from 2016) are practically equally abandonware and we have nothing to gain by requiring gadget/extension authors to upgrade their code now when they could be upgrading to e.g. OOUI, Mustache, or plain javascript instead.

In T71386#735153, @Krinkle wrote:

This is somewhat incorrect. Though andSelf is indeed deprecated, there are no plans by jQuery to remove it. It isn't part of the rest of jQuery Migrate and was not removed in jQuery core 1.8. In fact it still exists in the latest jQuery 1.11 and jQuery 2.x and thus jQuery UI continues to use it so that they don't have to feature-test andSelf/addBack for old versions.

Central on-wiki discussion at https://meta.wikimedia.org/wiki/Equals_sign_parser_function_template_conflicts.

Quick update: several other wikis appear to be affected. I'll give more details later.

I will investigate other wikis. This may take some time.

At least Dutch Wiktionary uses {{=}} for something different entirely. Other projects may be affected too. It looks like the parser function will override local templates. This patch shouldn't be deployed before wikis have been given a warning through Tech News.

For the first suggestion, there might be a concern that an undo can contain new content. If this is the case, you could:

1. Check if the performer has rollback rights and if so
2. Check if the submitted wikitext matches the preloaded wikitext and if so
3. Mark the edit as patrolled

In T256106#6247862, @Ammarpad wrote:

With JS or no JS, the link points to https://commons.wikimedia.beta.wmflabs.org/wiki/Special:Upload for me. Also note, that's where it suppose to point not Special:UploadWizard

When {{urlencode:foo bar}} is part of the MediaWiki message, it will no longer parse.

For even more options, additionally you could add this as well:

elseif ( count( $parms ) == 5 && ( $parms[1] == 'user' || $parms[1] == 'page' || $parms[1] == 'tagfilter' || $parms[1] == 'offset' ) && ( $parms[3] == 'user' || $parms[3] == 'page' || $parms[3] == 'tagfilter' || $parms[3] == 'offset' ) ) {
			$opts->setValue( 'type', $parms[0] );
			$opts->setValue( $parms[1], $parms[2] );
			$opts->setValue( $parms[3], $parms[4] );
}

Which would theoretically allow for example https://en.wikipedia.org/wiki/Special:Log/create/tagfilter/mw-new-redirect/offset/20200623121759 or https://en.wikipedia.org/wiki/Special:Log/create/user/Foo/page/Bar. (user:Foo should stop creating an article about Bar)

In T246879#6245224, @MarkTraceur wrote:

As suggested by AlexisJazz, maybe this isn't a bug in UploadWizard and should therefore be marked as Resolved or Declined and tossed back to an interface editor on Commons to fix in the wikitext?

On the other hand, it seems the call to the message in mw.ApiUploadHandler.js calls mw.Message#parse, so it's likely that the issue is the lack of argument. Perhaps if we don't receive data about the filename, we can/should use a different warning message.

In any case, marking as low given this doesn't appear to be a world-breaking bug and there's not a lot of opportunity for us to work on UW these days.

https://commons.wikimedia.beta.wmflabs.org/wiki/Special:UploadWizard

Content Security Policy: The page’s settings blocked the loading of a resource at https://api.flickr.com/services/rest/?&api_key=e9d…=json&nojsoncallback=1&method=flickr.photos.licenses.getInfo (“default-src”).

In T208188#6161225, @Aklapper wrote:

In T208188#6161207, @AlexisJazz wrote:

What do you mean by "this already works today"? It doesn't work on betacommons.

See T244124

In T208188#6160584, @Krinkle wrote:

This RFC is about gadgets and other user-generated scripts which are not reviewed and verified prior to being made available to users. For those, we need users to consent in a standardised way as the scripts themselves cannot be assumed or guruanteed to do this.

The foundation's privacy policy and general user expectations of privacy apply regardless of what technical solutions exist. Right now, UploadWizard already satisfies policy as it does not commnicate with Flickr from the user's browser unless the user interacts with that part of the feature, and even then only after it has warned the user about this. UploadWizard is installed on the server and can dynamnically add this third-party domain as needed to the CSP config for a specific special page. This already works today and does not need to change in any way. The system described in this RFC does not apply there.

In T208188#6159015, @Krinkle wrote:

@AlexisJazz What you describe (one-time permission for a specific third party, stored with your user account indefinitely) is exactly what is proposed and being built.

In response to the task description: I think it's a bit much to require re-authorization to add a domain. Or more specifically, I think it's very reasonable for unknown domains. I think it's very wise to require authorization to load http://1901529060.xyz/session.js. But 1901529060.xyz is not quite the same as Flickr. The Flickr import in UploadWizard already warns the user: "This form will load content hosted by flickr.com and subject to the Flickr terms of use and privacy policy. Please note that by using this tool, your IP address and request details will be available to Flickr."

Maybe we should break it down into even smaller bits.

In T253164#6150876, @Ammarpad wrote:

Then this would be duplicate of T2582/T88781

In T253164#6150162, @Aklapper wrote:

Extensions exist (see https://www.mediawiki.org/wiki/Category:Calendar_extensions ), hence I am closing this task as invalid.

If this however is a request to deploy some extension MediaWiki extension (which one?) on some Wikimedia website (which one?), then please see https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment - thanks!

Long story short: I believe the encoder part of XviD, revision 599 (XviD from 2002-10-16) will no longer be patent-encumbered on 2020-12-15.