In T387996#10641444, @pmiazga wrote:

@Catrope that's exactly the reason why Middleware works on batch/list -> not a single Notification - even at this moment this list usually has just one notitication. The idea behind this is to:

• allow easy Notification removal - we just "empty" the batch and then pass the empty array around - this saves us from null checks in code
• allow easy replacement/injection - in case Extensions want to replace Notification, remove it and/or inject their own -> they can do it with a list easily. When MiddleWare worked on the
• allow future deduplication - as an idea - in the future we can trigger NotificationService::process() only once on POST_SEND and it will go through all Notifications that were triggered within the request and remove duplicates, do batching, or, as an example - guarantee rule of one notification per one title - just an IDEA./

Sounds good to me too, this hasn't been used for a long time either, and given what it does, it should not be used anymore in today's technologies anyways.

In T385810#10556830, @pmiazga wrote:

Thank you @Mooeypoo for the update.

I'm wondering - did you consider an option where we can let Echo Handler fallback to MediaWiki - instead of implementing fallback handling inside MediaWiki? What I mean, for simplicity - if we want to make Echo handle everything anyway, plus the MediaWiki Legacy Handler will most likely be a service anyway. Then we would have only one "active" handler (in this case Echo), but then code in Echo Handler would have hardcoded fallback logic like if I don't know this Event, let me call the Legacy Handler.

Yes, notifications will not work on a clean installation of core without a provider -- either Echo, or another provider. This is current behavior, and is acceptable. Echo is bundled with MediaWiki, so 3rd parties will retain behavior, and anyone that installs "core" alone will need to add Echo for functionality, just like they need to add a skin (and just like current behavior).

We've had a conversation about this in the tech meeting, and here's our thoughts and summary:

I want to outline my concerns around providing (or not providing) a mechanism for "fallback" to use MW Core's straightforward 'email only' provider even if Echo is the available provider. I think that having a Provider take over the entire behavior is a valid course of action, and works with our intended architectural concerns, but there is one aspect that is user-facing that we should be aware of, and make a decision on.

In T385810#10532604, @matmarex wrote:

There are pros and cons for either of those options, and conversations so far have leaned heavily towards #2 (no Fallback)

I got the opposite impression, and I implemented option #1 in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1108511. I'd be okay with doing #2 too, but for me that increases the scope of the project, since now we have to make sure that every provider/handler supports every kind of notification, or the whole system will drop some notifications on the floor.

(I don't care if it's called "provider" or "handler", they are both meaningless words, so I chose the shorter one.)

In T385810#10529266, @pmiazga wrote:

There is also nit-pick when it comes to naming. A class that extension provides to handle/deliver notifications here is called "Provider". We had similar conversation in the gerrit PR: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1108511/comment/99b9bcb6_b81574d3/

@matmarex implemented Handlers as Echo would provide a mechanism to handle notification. Where Providers sounds more like a extension that would provide notifications, but it may not handle it.

In T221258#10182701, @kostajh wrote:

Is it possible this task could be taken up by the MediaWiki-Engineering group?

I tightened the description text and added a couple of more historical links.

Thank you!

Yes, it's indeed related. Apologies, we've updated the related wiki page and the mailing lists, but we haven't updated this ticket.

In T357077#9589547, @Jdlrobson wrote:

@Mabualruz the use of a composer library is in scope but doesn't necessarily need to be completed as part of this sprint but it must be discussed.

The important thing here would be to:

• present the options to the team and the associated trade offs (google doc)
• Facilitate discussion either async in the document or in person
• Collect a consensus about how we want to approach this.
• Document decision in an decision record (ADR) in the patch.

This is published: https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/Unraveling_Complexity:_Mapping_MediaWiki_Software_Components_into_User-Driven_Workflows

Summary from the MW Engineering Group after some discussion about this: As far as the MediaWiki Engineering side of things, this is done.

This is an interesting question. I think that what will help think through this would be listing our the implication and impact of either option.

This error looked extremely familiar to me, I believe this happens when OOUI isn't setup correctly.

In T322253#9431630, @Aklapper wrote:

@Mooeypoo: Is there still sense in keeping this ticket open and assigned to you, or can this be closed as resolved/invalid?

This is a really interesting feature!

This looks promising! And.... honestly, anything would have outlier issues in RTL. There will be cases you'll have to run around fixing no matter what you do (OOUI had that too) so you might as well start from something solid that gives you 90% of the functionality. In that aspect, I'd just verify it allows you to tweak / extend properly because you likely will have to with specific edge cases.

In T338817#9114988, @aishwaryavardhana wrote:

I don't fully understand what a user will see if we do a byte limit. Otherwise, Kosta's suggestions sound good to me.

In T301618#9108953, @Aklapper wrote:

@larissagaulia: Does "Radar" imply that the Platform Team does not feel responsible to clean up the docs and tickets of the predecessor(s) of the Platform Team?

There is a theoretically conceptual way to fix this but I think it's too convoluted to be worth it.

In T339156#8935507, @Esanders wrote:

The downside of this is that if you keep copying and paste back and forth between VE and GDocs, your headings would keep decreasing in level until they were all <h6>.

It all looks good to me (for some definition of good ;) -- the only thing I'd like to discuss and think about is the Artifact page. That page still has relevant documents, and some folks are adding to it. It could still be a good repository of analysis documents regardless of the existence of the team.

In T202916#8896779, @Quiddity wrote:

Previously, clicking on someone else's link to Recent Changes with filters applied within the URL, could unintentionally change your preferences for "Group results by page". This has now been fixed.

In T202916#8870777, @Trizek-WMF wrote:

How can we summarize what happens for someone who just land in this conversation? :)

Okay, I have to admit, I completely didn't think about the option of only triggering the "save preference" when the user manually clicks the checkbox; I think in my mind I thought that the distinction (between explicitly clicking vs the programmatic change of state) wouldn't be as clear to users as to when the state is saved or not.

In T202916#8860587, @KStoller-WMF wrote:

In general, this approach makes sense to me and I appreciate having the preference configurable in the moment of interaction, rather than buried in Preferences. However, the "Do this from now on" button either isn't working on Patch demo or doesn't match my UX expectations. When I click on Do this from now on, I expect to receive confirmation that something changed.

In T158725#7551584, @TheDJ wrote:

This is still a problem for the RC/watchlist modes which use tables. I also don't really see a solution to that, which does not include "remove tables".

This looks done to me, from 2018. Closing.

It is never good to see a frustrated @Whatamidoing-WMF, and so in my explorations of RCFilters (in preparation for a planned hackathon project) I have decided to don my cape and try to help.

Tracking ticket from Security: https://phabricator.wikimedia.org/T297791

In T312738#8305193, @Lectrician1 wrote:

Okay, I am now a Toolforge member. Just need @Mooeypoo to add me as a maintainer.

Yeah, I think that's a good resolution.
I might need guidance as to what to do to make this happen...

I was thinking a lot about this ever since we talked about this problem, and so I would like to offer a slight point here about being careful of over-optimizing for this problem.

Unfortunately, I'm in the same boat; I've never actually been directly involved in the project. I had a very passing general interest in it while working on another GraphQL project -- and I worked with the original maintainer! -- but I don't think I can serve as a maintainer on this (or even fix bugs...)

In T305091#7822743, @AnneT wrote:

So a MenuItem can have a label, a match (e.g a Wikidata alias), and a description. This task covers supporting a lang and dir attribute for each of those things. It's clear to me what a MenuItem should look like in a purely LTR or RTL context. But what about the following scenarios?

1. UI has one direction but all text nodes of a MenuItem have the other. For example, the UI direction is LTR but the MenuItem has an RTL label, match, and description. Should the entire MenuItem appear to be in RTL?

Feel free to share those wherever you deem fit :)

In T300053#7767004, @bmartinezcalvo wrote:

@Mooeypoo thank you for your great and useful feedback, I have update the Figma file with the following:

Another example for what I was trying to demonstrate is the "flipping" of the expected location of the negative sign

In T300053#7766024, @Huji wrote:

Can you provide some clarity/examples about what you mean when you say numbers with Eastern Arabic nuemrals are RTL'ed?

This figma file is absolutely incredible. For years we've been working on RTL support on the Wikimedia projects with some learnings and insights that were very rarely properly coalesced into a proper document with guidance and decisions, so having one being worked on not only as decisions for the specific Codex library, but as more widespread visual guidance is extremely helpful!

Icons and RTL are one of my favorite topics of philosophical musings that lead to practical visual decisions -- but they're usually really complicated, as the discussion here demonstrates.

In T258578#7607627, @TheDJ wrote:

Ok, applied bidi to some of the strings of TMH: https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-timedmediahandler-user&language=he&filter=&optional=1&action=translate

We will see how that pans out exactly. Also still needs to be done for the other rtl languages of course and the patch is required as well.

In T258578#7607375, @TheDJ wrote:

@Mooeypoo if you have some time, i'd love to pick your brain on this.

I'd love to try, but this is an interesting problem... I admittedly did not have a chance to go over any of the code yet, so I'm mostly offering some guesses here for now based on previous experience.

Not only is netlify self hostable, it directly connects to a github repository and gives you a myriad of deploy tools, including an automatic pull request preview, A/B testing with two or more branches, deploy out of a specific branch, etc.

Ah, localizing filenames on wiki, yes. One of the toughy questions, honestly.

(Add) -- also, you'll need to take into account the ability to let component users (implementers?) force directionality for content (so, input direction regardless of interface) and also force and set based on interface. I know we all know this, I'm just pointing it out because it might get a bit more complex with the prefix selectors.

This sounds generally good plan, I'm slightly worried about how exceptions may work with logical properties, but I think they should work in general.