Fri, Nov 27
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
Wed, Nov 25
This is a duplicate of T53980 I think.
Mon, Nov 23
@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.
Sun, Nov 22
Thu, Nov 19
Wed, Nov 18
The other text to finalize is that for the tooltips. At the moment it's:
Tue, Nov 17
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?
Mon, Nov 16
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).
Sat, Nov 14
Yes, this should be fixed I think. This is the link to the above work on the test site:
Fri, Nov 13
The last tweak to the fonts' list is merged and live on the test site.
Fri, Nov 6
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.
Thu, Nov 5
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
I think 2 points.
Tue, Nov 3
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).
Mon, Nov 2
@Demian Thanks. Edited (by Shirayuki).
Oct 30 2020
PR for this: https://github.com/wsexport/tool/pull/271
Done (on both test and prod), and the installation instructions updated.
Oct 29 2020
Thanks for finding those errors @dom_walden.
Is this the same as T244665?
Oct 27 2020
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.
Oct 26 2020
Oct 23 2020
@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.
Oct 22 2020
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?
Oct 21 2020
To do this, I suggest we do this: Add --branch option to deploy script
Oct 20 2020
The slash issue should be fixed now.
Oct 19 2020
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.
Oct 16 2020
I've updated the description above to clarify that we'll move the messages; feel free to change it more.
@ifried that's correct.
Oct 15 2020
- 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!
Oct 14 2020
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).
Oct 13 2020
Oct 8 2020
Oct 6 2020
Deployed to prod and test. All seems fine. :)
Oct 5 2020
Merged and deployed to prod and staging sites.
Oct 3 2020
Yes, I agree too, @Soda has done terrific work in the last months.
Oct 2 2020
A few things that might need some discussion:
Oct 1 2020
Share list of fonts supported by this change, so Ilana can inform the community & they can test out the changes when ready