A request has been made to support Wikibooks again: T268851.

Actually, we've been working in the other direction I'm afraid! See T266085: Wikisource Export: Drop Wikibooks support

This is a duplicate of T53980 I think.

@Dibya are you able to test this?

I've manually regenerated the OPDS file and copied it to the above location, so at least things work again for now.

The other text to finalize is that for the tooltips. At the moment it's:

The fix for this was on-wiki: https://pl.wikisource.org/wiki/Special:Diff/2647178

@ifried another question: should the extension prevent duplicate links from appearing? Or is it okay to have duplicates display for the short time between the new extension version being deployed and the old gadgets being turned off?

2.0.0 is tagged and released.

The ElectronPDF in question is this extension: https://www.mediawiki.org/wiki/Extension:ElectronPdfService (the Github link above is not correct).

Yes, this should be fixed I think. This is the link to the above work on the test site:

The last tweak to the fonts' list is merged and live on the test site.

There's a small bug with the new font list: T261479#6608064

Most of this is merged and on the test site, but there's a bug that @dmaza found with the padmaa font being listed twice (as padmmaa and padmaa-Bold.1.1). I'll make a fix for this now.

Different Wikisources show different formats in the sidebar links. @ifried Should we make it configurable to match the status quo, or just have a set list? Also, which namespaces should the links be shown for? I was wondering if we should show it on all $wgContentNamespaces. I haven't actually checked them all, but it looks like lots of the 114s below are just because they copied the gadget code from enwikisource.

Should be done before this: T266190: Wikisource Export: Migrate existing DB system to use Doctrine ORM

The first part of this is ready for review: https://github.com/wsexport/tool/pull/272

@dom_walden Thanks!

I think 2 points.

Installed, configured, and available now at https://wsexport.wmflabs.org/awstats . I've also documented it all on Wikitech.

Doing this now because we talked in the engineering meeting today about how it'll be useful to have before the switch to Symfony (later this week).

@Demian Thanks. Edited (by Shirayuki).

PR for this: https://github.com/wsexport/tool/pull/271

Done (on both test and prod), and the installation instructions updated.

Thanks for finding those errors @dom_walden.

Is this the same as T244665?

Oh, yeah and I meant to add: if the wikilivres site doesn't start working again soon, I think we should just remove the small bit of code that supports it from the tool. It can easily be added back again later if required.

Actually, this wasn't my idea, but I forgot to attribute it correctly when I copied the issue over from Github as part of T255512. The original issue was https://github.com/wsexport/tool/issues/22 by Tpt on Mar 22, 2013.

It looks like Wikilivres' API is not working. https://wikilivres.org/w/api.php redirects to https://wikilivres.org/

@SGill are you able to test this? The new font-handling on the test site supports a few different fonts for Assamese, such as Lohit Assamese: https://wsexport-test.wmflabs.org/?fonts=Lohit-Assamese&lang=as

We talked about this in standup this morning, and have decided that the font questions can be handled in separate tickets, so this is ready for QA.

Should we do these things?

The above patch is merged and deployed to the test site. I'm afraid I got it wrong about the Mukta fonts though, and they don't actually seem to be available in Debian. Oops. But others are for those languages, for instance Lohit-Tamil. I'll make a new patch to update the list, but first @SGill do you have an opinion of the fonts that should be in the list?

To do this, I suggest we do this: Add --branch option to deploy script

The slash issue should be fixed now.

That sounds like a great idea.

PR for stat: https://github.com/wsexport/tool/pull/253

Investigate if we can prevent automated downloads via bots & webcrawlers

To some extent we can, but it's unlikely to be completely foolproof. We're not looking to block absolutely all, however, but rather to just make sure they're not putting undue load on our systems.

I've updated the description above to clarify that we'll move the messages; feel free to change it more.

@ifried that's correct.

• The language is already set either via the ?lang= URL parameter, or extracted from the HTTP_ACCEPT_LANGUAGE header.
• The title can not be set automatically, because that's what triggers the book export. T256345 will fix this. We have to be careful to not make this a breaking change (e.g. wikis link to /book.php?lang=en&format=mobi&page=Lorem and expect it to trigger a download, so we'll have to use a separate URL parameter).
• The font is the biggest bit of work here I think. It'll have to be set based on the language, and also update dynamically when the language form field changes (but maybe not if the user has already made a selection?).

Thanks @dom_walden that's super useful!

PR: https://github.com/wsexport/tool/pull/248

Yes, that's a very good point, I was wondering that too. After T261480 we can look at the user agents more easily; should this task wait till that's done?

Each export is logged in a table with this structure:

Good point. I've added an alias for /tool/book.php (plain /book.php was already supported). Easier than trying to update all links on wikis (although it might be nice to do that in the gadgets anyway, at some point).

I've switched the test site to use the dev branch, and updated the docs on Wikitech for the new Apache config.

Deployed to prod and test. All seems fine. :)

Patch merged.

Merged and deployed to prod and staging sites.

Yes, I agree too, @Soda has done terrific work in the last months.

A few things that might need some discussion:

Share list of fonts supported by this change, so Ilana can inform the community & they can test out the changes when ready