Fri, May 29
I hope this weekend, but I'm not sure. I don't know if it's a complicated problem, it might just be a matter of setting the calendar TZ to match that of the wiki. At least that conceptually makes sense. You could probably release it as-is, because it doesn't actually fail, and by altering queries wiki editors will be able to work around the TZ issue.
Thu, May 28
Sounds good. I won't be able to make it at that time, but if enough other people can I'll look forward to reading the logs.
Thanks for the nudge @Aklapper. You're right, nothing is happening on this front, and I don't think anyone in WMAU has enough energy to take this on in the foreseeable future.
I've edited that page a bit, to update the section about advantages of DjVu.
Wed, May 27
I think there are some issues when wikis have a timezone set or maybe when dates are given with a timezone (from here). Will investigate soon... :)
Tue, May 26
Fri, May 22
@Krinkle do you think this should be reverted, or changed?
Thu, May 21
I think T178261 is a better answer for this bug. Why do we want to convert PDFs to DjVu? Commons and Wikisource handle PDFs fine, and IA still produce them and are very likely to continue to do so.
This seems more useful in light of T182470, where PDFs without text layers are not able to be turned into DjVu by the /phetools/pdf_to_djvu_cgi.py tool. It's becoming less clear as time goes on why we want to turn PDFs into DjVus anyway!
Okay, I've added a bit more detail above and created some more tickets. Moving to product sign-off as there's nothing to review or QA here. The various tickets can be dealt with separately; some may be unnecessary or invalid, but might help with ongoing discussions.
Anyone got a moment to look at the above patch?
Wed, May 20
Thanks @ifried. I've added the legend entry, and sorted out the other stuff.
Tue, May 19
One of the assumptions has been that we don't want the watchlist_expiry or watchlist tables growing too big, but it sounds like this isn't actually the crux of it. If all the places that use the watchlist tables do so with proper limits etc., then is it correct to say that we don't mind these tables getting large? In T245866 we mention 'DB constraints', and T240094 has discussion about limiting to "prevent possible abuses" and to ensure we don't try to purge all at once (which we're doing), but it doesn't seem to be spelled out anywhere that the absolute size is the problem.
even the exception handlers aren't set up.
Mon, May 18
So I'm not sure what's happened, but after a few weeks of disk usage hovering around 95% it's now more like around 70%, which is what the cron cleanup command gets it to when run manually. So I don't think there's anything more required here. I'll leave the above patch for now, because it doesn't seem to be required, but we can always come back here if need be in the future.
Fri, May 15
We're going to have a similar tooltip in Special:Watchlist (T250212), where the phrase is "expires in XX days". Maybe that could be used here too?
Thu, May 14
I was thinking the deprecation process would be along the lines of:
Good idea, @Glrx. The patch above adds a general 'unsupported SVG' error, which can be given different reasons for each thing. It doesn't handle textpaths yet, but after it'll be easy to add that.
Wed, May 13
I and @Prtksxna talked about this and decided that using flexbox for the HorizontalLayout results in the best layout and behaviour:
Tue, May 12
Mon, May 11
All done! Thanks everyone.
The prod instance is now at https://svgtranslate.toolforge.org/
Fri, May 8
New consumer for prod is waiting approval: https://meta.wikimedia.org/wiki/Special:OAuthListConsumers/view/f9bc46beb85cae38645773215c4246d5
Test site is done: https://svgtranslate-test.toolforge.org/
Thu, May 7
No, I just meant that if there was anything missing, it'd be better to build it in a general-purpose iCalendar library rather than one-off for Cargo or MediaWiki.
For basic things, it's not too hard to construct icalendar manually, you're right, but I'd like to support extra things like calendar availability, complex recurrence rules, alarm triggers, maybe RSVP stuff. Not sure how easy those will be to reimplement, and if I did I'd sort of rather contribute to a library that's not just for Cargo. The specs (RFC 5545 and half a dozen others) are quite complicated, and even just things like character escaping and line wrapping can be done wrongly. Not to mention that there are so many different clients that can read icalendar, lots of which do their own thing (not to name anyone by in particular, Google). It's nice to have a single library take care of all that.
Wed, May 6
(We posted at the same time above.)
No worries. See what you think. :-) It's current use case for me is for a Wikimedia Australia events feed.
@Yaron_Koren do you think this is a good idea?
Tue, May 5
@ifried what do you think of the above messages?
Mon, May 4
Yep, it seems that it is Commons doing something inconsistent. The tool looks at the Content-Type header of the response for the SVG file, and fails if it's not image/svg+xml (which happens, as you say, when <?xml version="1.0" encoding="UTF-8"?> is missing).
Good ideas! Thanks. How about:
Sun, May 3
Another possible workaround: https://github.com/wikisource/wscontest/pull/14
May 2 2020
Maybe reproducible with:
Possible workaround: https://github.com/wikisource/wscontest/pull/13
There isn't such a button because it's basically the default: as soon as a contest is saved, its scores will be generated on the next run of the score-calculating job (once per hour).
May 1 2020
I'm not sure if this non-inline display is intentional for non-checkbox fields, but there's nothing in the docs about it being different for different widget types.
Apr 29 2020
It looks like it's possible to show a specific error about the nested tspans. Would we want this to also display the SVG fragment in question, to help with debugging? Something like the following:
This is ready for QA. The ClearUserWatchlistJob is used when a user has more than $wgUpdateRowsPerQuery items in their watchlist (default 100).
The only breaking change might be T177906: [mediawiki-api] Move to vendor/package style namespaces (PSR4), but it's probably not worth it (feel free to decline that ticket if you don't think it's a good idea).
Apr 28 2020
Unfortunately, the above patch introduced incompatibility with MediaWiki 1.32, because it uses LESS variables that have been renamed since then. I'll make a follow-up patch to fix this.
@Akinwale-microsoft can you try the latest version and see if the colour changes are sufficient?
Apr 27 2020
Thanks for looking into it @bd808. I haven't been able to figure out what's going on.
Apr 22 2020
Apr 21 2020
Except you probably won't end up with the right extension version;
Oh right, yeah I didn't think you meant you'd do it. :-) It's a good idea to match the existing design! I'll do my best...
@Volker_E I tried to do that in the above patch (but didn't check it very thoroughly; I've updated it a bit today).
Apr 20 2020
Apr 18 2020
Apr 17 2020
It seems that it's possible to change the repo name here (but not delete it). I didn't realise that earlier. So I've changed its name (which unfortunately also breaks existing links to https://phabricator.wikimedia.org/source/tool-ws-google-ocr ). The new repo is rWSOCR.
This is waiting for T249730 and then Harumi's going to do the final deployment (so am changing assignee).
Does anyone have any more thoughts on this? Should I go ahead and create tickets for any of the above?
Would the removal of the current partial support affect that use?
I think the main benefit is ease of installing and upgrading extensions.
Apr 16 2020
Oh right, that's good to know. Then it sounds like we'd have to remove the mergability of the require section of composer.local.json if we wanted to prevent people from installing extensions with Composer. Extensions would still have their own require section of course, but only include would work at the higher level.
I agree with everything @CCicalese_WMF has said above. Let's figure out a middle ground here; installing extensions with Composer is really useful!
Testing the latter, I am finding that watchlist_expiry rows are not removed when deleting an item with Special:EditWatchlist/raw.