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.

I've edited the task description to remove the examples where the files were actually corrupted (as I had previously noted above), and added the files which (to the best of my knowledge, please correct me if I'm wrong) exhibit the issue due to the same cause (large metadata field).

In T107664#1756357, @Bawolff wrote:

File:Толковый_словарь._Том_2(1)_(Даль_1905).djvu looks like it works now. Is that the file you are referring to? If you mean an old version, could you link directly to which version so I know which file we're talking about?

@matmarex does that date correspond to the #wmf-deploy-2015-10-27_(1.27.0-wmf.4) tag? I'm asking because it's a day later. If it does, I wonder if the naming scheme of the tag here in Phabricator shouldn't include dates like that, or make it clearer it's the start of a period (maybe something like "wmf-deploy-2015-weekXX" or "wmf-deploy-2015-oct-i", -ii, etc.).

@rosalieper please don't re-add people to the subscriber list after they've removed themselves!

Is this kind of problem something that could be made visible in http://status.wikimedia.org? Everything currently tracked there shows up as green (service operating normally).

Some further info: using djview, the errors seem to be clearer (they show up by scrolling down the thumbnail list):

$ djview -verbose Ten_Years_Later.djvu
djview: INFO: [1-12515] file://localhost/home/waldyrious/Ten_Years_Later.djvu/tenyearslater00duma_0393.djvu FAILED.
djview: ERROR: Unexpected End Of File.
djview: INFO: [1-12515] file://localhost/home/waldyrious/Ten_Years_Later.djvu/tenyearslater00duma_0394.djvu FAILED.
djview: ERROR: Unexpected End Of File.
(...snip...)
djview: INFO: [1-12515] file://localhost/home/waldyrious/Ten_Years_Later.djvu/tenyearslater00duma_0521.djvu FAILED.
djview: ERROR: Unexpected End Of File.
djview: INFO: [1-12515] file://localhost/home/waldyrious/Ten_Years_Later.djvu/tenyearslater00duma_0522.djvu FAILED.
djview: ERROR: Unexpected End Of File.

It appears that the Ten_Years_Later.djvu document contains 521 pages, but pages 393-522 are missing (maybe the file was truncated?), which corresponds precisely to the 129 times the ** (evince:13241): WARNING **: DjvuLibre error: DjVuFile.cpp:2249 appeared in the evince output for this file.

Here are the results I got (empty lines and duplicate lines removed from output, for compactness):

I've re-pinged @Ernest-Mtl on-wiki. Without access to the file before it is uploaded to commons, I can't test whether something goes wrong during the upload.

That's good to hear. I wonder if that approach (i.e. script-based) can be extended to all free-form documentation checked into git, and if so, whether it can be run automatically on each push for review -- like TravisCI does on Github. If that is both possible and planned, I would support not only keeping the current docs in git, but also moving mw.org code there. However, I suspect the less structured the documentation is, the harder it is to do automated checks like this, hence my inclination not to rely on review culture alone to keep docs in sync with code (especially since git-hosted docs are harder to edit for occasional contributors, when the very fact that they're free-form makes such contributions more likely).

In T111298#1602035, @hashar wrote:

An example is the docs/hooks.txt which is updated atomically with the code changing hooks. So it makes sense to have the doc in sync with the code.

In T111298#1601068, @MZMcBride wrote:

As I said on T111283, if we keep these files around in Git, I think we should consider just making them pointers to mediawiki.org.

In T94562#1600837, @3BRBS wrote:

I runned the code in the snipet (in Firefox the web console is opened pressing Ctrl+Shift+K) and got this: