I thought of some more features and I thought I'd document them here:
I don't see a reason why not... my only concern is that... there are no version numbers. I suppose there could be version numbers for the git repo (and those don't necessarily have to line up with the docker tags), but maybe that is more confusing?
Thu, Aug 16
Does Hugo's i18n support work with translatewiki.net? or would you be using something else for translations?
FYI: I moved the React bindings for jQuery.i18n into it's own library:
Wed, Aug 15
What timezone should https://foundation.wikimedia.org/wiki/Template:DMCA_email be in? UTC? or should it remain in west coast timezone?
I don't know anything about our logging. :) but it does look like you can use Graphite, or you can also use the schema (db?) logging from the client. So we should be golden either way. It also looks like MobileFrontend is using mw.track (Graphite) for most of it's logging (as far as I can tell).
We can also use statsv which is just an HTTP endpoint
It looks like Graphite will listen to EventLogging extension:
Event logging has a method for client-side events:
Tue, Aug 14
Mon, Aug 13
@TBolliger Do we have any idea how many admins are looking for this feature?
@Krinkle oh. that's fascinating. Is there a standard way to determine if the user has a session?
All that makes sense to me, and I agree that I don't think disabling the feature should mess with the database.
@dmaza I think T197117 is the next task in the graph, but if you can complete this one before it's subtasks than go for it, but I think we figured that wouldn't be possible for some reason? perhaps the log only tracks when they are saved?
Fri, Aug 10
Thu, Aug 9
I've been thinking about Wikidata a lot, and asking "What is the reading experience supposed to be like?" and I though about data websites that I read a lot, and one came time mind: IMDb. While I was at Wikimania-Hackathon-2018 I started work (ok, I haven't done much) on a IMDb clone that uses wikidata:
running prototype: https://wikimdb.davidwbarratt.com/item/25188
@tstarling wow thanks for your detailed comment!
Wed, Aug 8
Tue, Aug 7
What happens if someone creates a Partial Block (with the new UI) but then someone tries to edit the block (with the old UI)?
@Huji I completely understand the use-case and I agree that this is a problem that needs to be resolved. We created T194697 and after some investigation, we discovered that it's effectively a completely separate project that has no relation to this project at all. The only relationship is that... it's somewhat pointless to create multiple sitewide blocks for the same user/ip. We could do T194697 before doing this project, but what would be the point? At the same time, adding T194697 to this project constitutes scope creep since there isn't any overlap between the two. The irony is that this task (as well as T104099 & T6995 which are also separate projects) exposes the multi-block issue that wasn't a problem before. We are effectively creating a new problem (and perhaps that's not a bad thing).
It seems that the consensus view is that a language picker should exist on the page, but the default should be inferred from the browser's settings.
@stjn The hope is that partial blocks (pages and namespace) will help mitigate conduct issues. If that's not the case, then this isn't something that Anti-Harassment should work on. I think there's probably a lot of overlap, but I think if we can help prevent small issues between users from "blowing up" into huge issues by adding a partial block to the user, then that's a big one. For instance, if two users are getting angry at each other over content, from what little we know, that can quickly cross the line from being a simple content dispute to becoming a conduct issue. In fact, it's our purpose for building this in the first place:
Smaller, more tactical blocks may defuse situations while retaining constructive contributors. The goal of this project is to give wiki administrators a more robust set of tools to be able to better respond to different user conflict situations.
Mon, Aug 6
What do we think?
What do we think?
This doesn't show in the screenshot, but the text within the box is focused and selected (ready for a copy/paste).
I'm also not sure how these numbers are being calculated, the most I can get up to (on desktop, no cache) is 3.49 MB on Firefox and 3.2 MB on Chrome. For context, this article https://en.wikipedia.org/wiki/Universe transfers 1.6 MB on Firefox and 2.3 MB on Chrome.
I suppose it would be helpful to better define the problem... is it the amount of data or the performance that is the problem? Those two problems might have different solutions (although there is some overlap).
I'm not sure the title of this is accurate, while initially I thought that perhaps it was a lot of resources, I ran a Lighthouse Audit and even when throttled to a "Fast 3G Connection" (which, tbf, is probably faster than most people have, I don't have any data though) the homepage receives a top score (on desktop and mobile). The audit does however give opportunities for improvements without changing the design (i.e. using next-generation image formats, making the site offline-first, increasing the cache length, etc.)
Thu, Aug 2
@Mooeypoo This is only really a problem for new admins, or if we add something to the top of the page we want people to notice. I suppose in hindsight we should have added it after the help text.
@Mooeypoo, I think @TBolliger had an idea of making the help contextual (i.e. it would changed based on what you typed in) which I think is a great solution, more complicated, but it only presents the help when you need it.
Oh! my apologies.
My assumption is that this would be a change to Special:Block