Note another relevant task (a child of T163433) that we will also implement as an entry point to Category search: T195481: Create entry points for the category filters
This is in addition to typing the trigger '/' in the filter menu.
Wed, May 23
I believe there's work to migrate category select (mw.widget) to TagMultiselectWidget... @Volker_E ? Any ideas if that's going on?
The MVP will definitely just use another button in the row (no dropdown menu) so we can take a look at that and see if we want to iterate. The initial implementation will not include a dropdown menu, even just for practical reasons.
It was before, it was changed to the Category filter task now.
This is great, thanks!
Tue, May 22
To add to the list, we have this also in RCFilters:
(Though to be fair, we had to extend the functionality there a bit to have sub-menus and to have an "edit" capability, but the base is still a vertical group of buttons)
Sun, May 20
Sat, May 19
Tue, May 15
Yeah, please do not implement user filter. In the current GSoC project that is working on this, we pivoted to Categories after discussions with the Anti Harassment team and product managers.
@Krinkle all of this is great work, thanks for leading it. I wanted to help with rcfilters, but if I go by the standard you put up, it seems it's already organized into its own folder anyways. We already organized the files inside based on logical structure (dm/ui/styles etc) so I'm trying to see if I'm missing something. I mainly ask since it's in the TODO list in the description, so I want to verify in case you want to rearrange something or if they're "passing" by default...
Mon, May 14
I can't reproduce it in master, I don't have display:flex applying to this class. @Catrope do you know where is this coming from?
Sat, May 12
Fri, May 11
Thu, May 10
Wed, May 9
This color scheme was approved (and guided by) @Volker_E
Tue, May 8
Helpfully, these are messages the code creates automatically, but that don't have actual text.
eek; it was a combination of an older condition with the padding/placements that the new widgets used.
This is actually not straight forward at all. It's not just counting how many markers there are, but specifically how many numbered counters there are. If we just count markers, then there are iconed markers who shouldn't be a problem at all. The issue is when the numbered ones are over 99 and start displaying numbers that don't fit the marker area.
Mon, May 7
Sun, May 6
Fri, May 4
The idea sounds great, I am just confused about what it actually means; what conventions are we going for?
Wed, May 2
I'm replacing the concept of setDisabled() on an item with a setStatic() on an item; this will (a) prevent the bad behavior when the entire widget is disabled, and (b) properly separate the actual meaning of wanting to specifically "disable" a single item inside the widget -- which, really, means, it's not disabled, it's just "always included" and is static.
This also means that T181578: Backspace allows editing/deleting disabled items in TagMultiSelectWidget will be changed; )
Tue, May 1
Yowza, nice catch, thank you!
Following up, here's a screenshot from a Hebrew news site that uses video. See the "Play" buttons are all in LTR:
Ah, this is a fun one. I'll poke @Amire80 for this too, since we've been having this similar discussion several times, but since this was reported by @IKhitron who's a Hebrew speaker, I want to see other opinions here.
Mon, Apr 30
Sat, Apr 28
It's not locked; The code is available, we need to review, fix it, and merge. Is anyone actively working on T189391: New block option: Notify me when this block is about to expire or has expired ?
Fri, Apr 27
The second they choose an item and the menu doesn't close, the user understands the widget allows for more items.
Wed, Apr 25
After a bit of discussion on the ticket, I've merged the code. It's a good fix for the current completely broken behavior.
Apr 25 2018
We should definitely fix it. The menu hides itself after choose, and only reopens on focus - but in these cases, the focus is ALREADY on the input, so it doesn't reopen. We need to fix it.
Apr 24 2018
Apr 23 2018
Apr 20 2018
Aramaic is probably my fault; there are several options for Aramaic, I went with Imperial Aramaic, it might not be correct?
Apr 18 2018
Apr 17 2018
Apr 15 2018
Apr 14 2018
Apr 13 2018
Based on comments on the patch, I reset the item list to be OOUI buttons so that they follow the accessibility requirements, and also that they work the same in Apex, which the previous <a> design didn't have.
Pulling it back to 'in development' to work on the fixes with a followup commit.
Copying my notes from the patch, because there's still a small visual bug that cannot be fixed:
Apr 12 2018
I implemented the hover color in the current patch. I'll poke the team about reviewing it.
Apr 11 2018
Apr 9 2018
@Pginer-WMF I've implemented the mockup to the best of my ability without the accurate distances. It looks fairly close to what you have.
Apr 6 2018
Apr 5 2018
The main issue is that layers are configured per wiki, so the "base" state of the map is having no layers (like in mediawiki.org) and hence, no sidebar.
"Nearby articles" is also only working for English Wikivoyage for the moment. Making it work in other wikis is possible, but is not trivial.
Apr 4 2018
I updated the patch, it has conditional display between save and publish now.
But in Elena's screenshots, it doesn't look like it's the fullscreen version, either.
This is a really weird bug that seems to have different behaviors in different places.
The above commit removes wikidata only, and leaves image attribution; if we want to remove the image attribution too, we could fix the commit or followup.
Looking at the code, we're also gathering attribution for "page" which are images from commons. I can't find an example live for this, so I'm going off what I see in code, and it's done exactly the same as the wikidata collection -- do we want to take those off too, or just the Wikidata links?
Build passes; nothing to QA. Resolved.
Apr 3 2018
@Volker_E .... could this have to do with the OOUI icon changes?
Apr 2 2018
Is this ready to be worked on?
Just to delve deeper on how to approach this; if we are going to have each of these messages (multiple messages with "save" that should say "publish") then the fix is getting a little more elaborate.
I just noticed the existence of this: