In T173214#4457079, @Tpt wrote:

For statement filtering by qualifier a good solution is maybe to add an extra parameter "hasStatement" to the statements field and give to it a value of type SnakInput (a GraphQL input type that would be used to encode a snak provided by the GraphQL client). What do you think about it?

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?

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:
https://www.npmjs.com/package/@wikimedia/react.i18n

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
https://wikitech.wikimedia.org/wiki/Graphite#statsv

It looks like Graphite will listen to EventLogging extension:
https://wikitech.wikimedia.org/wiki/Graphite#EventLogging
Event logging has a method for client-side events:
https://www.mediawiki.org/wiki/Extension:EventLogging/Guide#Underlying_technology
examples:
https://www.mediawiki.org/wiki/Extension:EventLogging/Programming#Client-side_logging

https://github.com/wikimedia/takedown-tools/pull/12

In T199917#4500009, @aezell wrote:

! In T199917#4499879, @dbarratt wrote:

That question looks like it's related to T194697. We have no plans to change the UNIQUE index in this project.

@dbarratt or @dmaza correct me if I'm wrong. We also believe that even if there were "duplicates" created, the effect would be exactly what it should be. The user would be blocked from the intended actions/pages/whatever for the intended amount of time. We will ensure that the display of existing blocks won't break if there are multiples.

In T199917#4499867, @TBolliger wrote:

Tim's question of unique index (which are currently used to address the situation when two admins attempt to set a block at the same time.)

In T201853#4499045, @TBolliger wrote:

This may be an insurmountable blocker for database reasons.

@TBolliger Do we have any idea how many admins are looking for this feature?

@dmaza In hindsight, we should have probably determined if the user had a session and then set the cookie T194396#4498543

@Krinkle oh. that's fascinating. Is there a standard way to determine if the user has a session?

In T194396#4495919, @Krinkle wrote:

This implies there exists logic that obtained information about the current user in a way that was insufficiently conditional (on there being a session), determined a cookie to want to set, and then wants to know whether doing that is safe.

We usually do things the other way around: The logic should not obtain such information or compute values to be set unless we determine that the current request is session-based (e.g. user agnostic, or user specific). If a session is available, information may be read and used, otherwise it must not.

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?

@TBolliger Does this ticket involve splitting out T194697 into smaller tasks like we did for T2674?

In T189839#4492789, @MusikAnimal wrote:

That is the point, I thought. There are numerous tools that use Intuition, or it's cookies. At the least it probably won't be of any surprise if the user sees other tools in the language they selected.

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
code: https://github.com/davidbarratt/wikimdb

In T194697#4492140, @dmaza wrote:

1. Is there a reason why bt_auto exists in block_target instead of block_entry. It feels to me that autoblocks can be just another entry

@tstarling wow thanks for your detailed comment!

In T189839#4490562, @dmaza wrote:

If we are gonna set that cookie we somehow need to inform the user that language selection is shared among the tools in the domain. Otherwise it is an unexpected side-effect to select a language in one tool and have it carried over to another.

In T189839#4489764, @dmaza wrote:

If I remember correctly we are handling translations on the client side of the app so we can't use Intuition. We could use the cookie if it exists but then we'll be considering something that is not part of our dependencies. I think that https://phabricator.wikimedia.org/T189839#4485397 is the way to go for now.

In T200957#4486691, @Varnent wrote:

There are some built-in RSS feeds for Wordpress.

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.

https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking#Use_cases

In T197148#4483261, @kaldari wrote:

Not sure if you're planning on doing T189839 or not, but if so, you might run into space trouble with other languages like German ("Teilen Sie diese Ergebnisse"). Maybe just "Share" would work better. Sorry to add more bikeshedding :)

What do we think?

In T197148#4481869, @TBolliger wrote:

David — when the dialog opens, is the text automatically selected?

Yes.

In T197148#4481737, @aezell wrote:

How does the dialog handle smaller screen sizes? Is it fixed or fluid in size?

What do we think?

On the schedule!
https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20180806T1800

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.)

In T200964#4474795, @TBolliger wrote:

If I understand correctly, David is suggest to keep the behavior that typing after landing on the page will still popular the username/IP field.

@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.

In T200964#4472975, @TBolliger wrote:

David, do you know if this will this require a change to OOUI or to Special:Block?

My assumption is that this would be a change to Special:Block

MediaWiki-Docker is the project tag for https://hub.docker.com/_/mediawiki/ and is also referenced in the repository's README https://github.com/wikimedia/mediawiki-docker