In T195756#4239426, @Ladsgroup wrote:

Indeed, we were thinking of having a special page called ""Special:DsiabledSpecialPage" in such cases but building that is outside of our scope for now.

Just for completeness, I'm copying the comment I added in T195754:

We don’t want any of those

FWIW, I use this quite often (manually), when the search results are too numerous and I'm looking for items with a specific name, since the intitle: operator doesn't work for Wikidata items.

Is there any way an error message could be shown to users to explain why Special:ItemDisambiguation is being redirected to Special:BlankPage? It's quite puzzling for someone who isn't aware of the current issues.

In T166272#3437125, @Jdlrobson wrote:

For those who want well formed HTML we will be providing a new service on RESTBase which will guarantee that (please follow along with T113094)

Can anyone comment on why the patch hasn't been merged? I can't see any outstanding review issues, but I may be missing something.

I've also been seeing this problem on Wikidata. Here's a screenshot of the issue, as an additional data point:

Note that the Abuse filter was just a stop-gap measure while we finished the setup (which has been taking longer than we'd like), it wasn't meant to be permanent. I personally would prefer not making well-meaning editors with established accounts on other Wikimedia wikis (like MarcoAurelio :)) jump through hoops to make edits. But that's something we can look at later down the road. For now the fishbowl approach is probably the quickest solution.

On a slight tangent: during the import, we're taking care to avoid importing all pages indiscriminately, to reduce some of the cruft (templates, redirects, images from commons, etc.) that accumulated over the years. It would be very helpful to this effect if we could run maintenance scripts on the wiki during the import process. Would it be possible to install Extension:Maintenance? If so, let us know if you'd prefer a separate issue to track that.

I need to be able to get the formatted extracts either via the old api.php or the new REST service. If a new endpoint is created providing such extracts with well-formed HTML, yes, that would work for me.

Those weren't really sensitive (in e.g. the legal sense) documents, just internal organizational stuff that didn't make sense to be published, so there's no significant risk for us (in fact, most of those documents aren't event current anymore). We already have plans to deal with that content, and were just making sure there weren't new recommendations for that use case. Thanks all for confirming.

In T126832#3224558, @jcrespo wrote:

waldyrious- no data existe live anymore of the old wiki (only temporarily on backups), not even on labs.

In T67169#3221431, @Jdlrobson wrote:

I think this task is exactly the same as what we are talking about in T113094 and its subtasks ?

In T126832#3221503, @jcrespo wrote:

We do it normally as long as it is not private (the text written there is open to the internet).

IIUC, that is not exactly what this request is about: currently I'm using a request like https://en.wikipedia.org/w/api.php?action=query&prop=extracts&exintro&indexpageids=true&format=json&generator=random&grnnamespace=0&format=json, which returns a html-formatted extract. The problem is that the html is not guaranteed to be valid, hence it fails if embedded in a xhtml page (or any other context where well-formed xml is required).

Thanks everyone, much appreciated!

Just pinging to make sure this hasn't fallen off the radar :) is there anything blocking the scheduling?

In T20640#3156907, @Peachey88 wrote:

https://static-bugzilla.wikimedia.org/18640

Can someone clarify when/why this was closed as declined/wontfix? I can't see that in the activity logs of this task -- perhaps it's a detail that wasn't preserved in the bugzilla import.

I'm a bit confused by this issue. Judging by its title and description, isn't it the same as T62437? And if so, isn't it resolved already? If not, it probably needs clarification.

Sorry all for the spam caused by adding & removing this task from Wikimedia-site-requests. I was trying to get a list of wikis where this extension has been/is planned to be enabled, and I came up with this query, which suggested that the combination of Wikimedia-site-requests and ArticlePlaceholder was the right way to get this information. Please let me know if such a list is being maintained elsewhere.

In T3790#3015475, @Jdforrester-WMF wrote:

In T3790#3015429, @srishakatux wrote:

Any updates on this task? Would this be suitable for GSoC or Outreachy? We are currently recruiting projects and mentors for May-Aug 2017.

T132058: 3d extension supporting STL (3d printing files) is mostly complete, and will mean the main request here is Resolved, so no, I don't think it'd be a good fit.

OBJ would be a good format for open 3D models because it has an exclusively text-based representation, contrary to STL (T143201, T132058), and PLY (T145499), which can be either ASCII or binary. What's more, STL files are often saved in the binary format by default, while providing no no surface distinction --e.g. in the filename extension-- which would allow distinguishing them from the ASCII ones.

I've created Category:WebP file format and Category:WebP files to track WebP (and WebP-related) files. I think I've collected all of them at the time of writing.

Indeed, the WMF logo is in the bottom row of the logos grid, but still part of that grid, so the main issue remains. Considering that the page contains 16 logos in a neat 4x4 grid, we could still have a perfect 5x3 grid if we removed one logo from there, so not even aesthetics would be sacrificed with such a change.

In case this helps, I am also using Firefox (50.1.0) and have the uBlock extension installed.

I don't think we should be the ones to choose where to put the emphasis. It could well be that newcomers to Wikimedia development would be interested in working on high-impact issues (the same reason why editing articles on Wikipedia and having the result immediately published for all to see is attractive), which may include submitting changes to core MediaWiki. Are there any processes through which we could collect what documentation resources people are lacking the most? Maybe the Analytics team has collected / can collect some data in that regard?

In T149372#2755614, @Tgr wrote:

Coming up with some sort of checklist/guideline/best practices for writing effective documentation would be cool.

Since two hours is way too little time to make a considerable dent in the actual documentation needs, I would suggest using that time to work out higher-level issues, particularly figuring out what's needed and defining immediate next steps for:

@Qgil I'd be very interested in a proposal around this, but honestly the nature and scope of the expected activities for the summit aren't clear from the CFP page. Maybe one or two generic examples, or ballpark estimates in terms of expected duration, level of structure, type (hands-on, discussion, presentation?...) would be useful. Or even some highlights among current proposals which could serve as inspiration.

Thanks @demon! Let us know if there's anything you need from our side.

Thanks @Nikki, I'll mark this as a dependency.

Thanks for the clarifications, @Krenair. SpecialInterwiki isn't critical, just a nice-to-have. Configure, OTOH, would be really handy, but I understand there are concerns about its usage -- it was a long shot, but I thought I should at least ask.

Oh, also, if that's still a possibility, it would be nice to use "WMPT" and "WMPT Discussão" as project / project talk namespaces.

Sorry for not commenting sooner, but if possible, we'd also like to have at least the CategoryTree, EasyTimeline, PdfHandler, ParserFunctions and SpecialInterwiki extensions installed. I'm not sure those are installed by default on all such wikis. Something like this: https://nyc.wikimedia.org/wiki/Special:Version would probably cover most of our potential needs. I would also ask for the Configure extension, if that would be ok.

I've created a category to make it easier to find examples where mask rendering fails.

Hurray! The fix worked :) I've created Category:DjVu files with errors for the files that are themselves corrupted.

In T107664#1766927, @GOIII wrote:

In T117013#1765062, @gerritbot wrote:

Change 249724 had a related patch set uploaded (by Rillke):
Parse huge XML metadata from DjVu images

https://gerrit.wikimedia.org/r/249724

Please get Gerrit to merge this... the sooner it gets rolled out, the sooner we'll know if all the mentioned cases are resolved or not.