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.

In T178387#4228563, @Volker_E wrote:

In a conversation, @Pginer-WMF and myself tried to find a balance when to use a callout triangle. Our proposal:
Whenever a popup replaces a dialog, it should have a callout triangle. All of the above showed examples are on the menu side, so shouldn't feature a triangle.

In T193389#4226126, @Volker_E wrote:

@Mooeypoo I've mentioned the corresponding task T183299 above, in my understanding WMDE team is taking on the work (which can be oriented on similar ones already linked there) and will reach out to us if they run into problems. Everybody fine with that?

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.

In T178387#4222188, @Esanders wrote:

See the above patch to Echo. $( '<a>' ).attr( 'href', '...' ) can be passed to $element in the config, giving you right/middle click functionality, and normal selects can be handled with location.href. This could be packaged into a LinkMenuOptionWidget, and handled upstream. The CX user menu does something similar.

It was before, it was changed to the Category filter task now.

This is great, thanks!

In T178387#4222018, @Esanders wrote:

That ties into having, in general, a non-disappearing "menu" behavior like a better implemented OO.ui.SelectWidget

I think OutlineSelectWidget / OutlineOptionWidget, although named as if it can only be used in a BookletLayout is actually very suitable for these static list scenarios.

We may want to create a parent classes that have a more generic names, and removes some of the methods only called by OutlineWidget (e.g. move/remove), but for now it should be perfectly usable.

In T178387#4121263, @Esanders wrote:

I'm thinking this could be done with some small changes the DropdownWidget, such as making the handle frameless, and not changing the label when an item is selected.

To add to the list, we have this also in RCFilters:

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

In T153011#4205169, @Jpgordon wrote:

Well, running with "debug=true" makes the thing that loads slightly slowly

• the filter thing on top of "related changes" -- load incredibly slowly; without debug=true, it takes 4-5 seconds to load; with debug=true, it takes more like 25 seconds. I am seeing several of these in the Firefox debugger

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?

In T194228#4201986, @Volker_E wrote:

The position of the original leaflet icons isn't correct (they are too far right). Is there a task for it?

In T193428#4195273, @Etonkovidova wrote:

@Mooeypoo
However, when clicking on "View more", the horizontal scrolling appears. I vaguely remember that it's extremely difficult to disable horizontal scrolling if a vertical scrolling is in place, so maybe we should be fine as it is?

In T112948#4194622, @Yurik wrote:

@Ghuron use nolabels=1 parameter.

In T192701#4192217, @CKoerner_WMF wrote:

The important bit here, in my opinion, is that for these things we have to have some community agreement

Agree. It's also super hard to preemptively ask communites what they would prefer. Posting something to every Village Pump would give us far less feedback than we'd desire.

I'm not saying that's what you're asking here @MSchottlender-WMF, but just a truism as I think about this. :)

I tried to add clear documentation on how community members can request a change to the fallback chain. This would, presumably, also include requests to not fall back to English. I think this would suffice in most cases. If/When a community discovers a fallback they do not want, they can build consensus to change, and file a task for an update to the list. Does that sound agreeable?

https://www.mediawiki.org/wiki/Help:Extension:Kartographer#Map_language_fallbacks

This color scheme was approved (and guided by) @Volker_E

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.

In T155290#4186714, @IKhitron wrote:

I really need a way to add category to json pages.

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.

In T192701#4183412, @Etonkovidova wrote:

(1) https://github.com/kartotherian/babel/blob/master/lib/fallbacks.json file is limited in defining fallbacks for some common language, e.g. no fallbacks for Russian, Ukranian, Greek, Belorussian, Bahasa (Indonesian), Hebrew etc. English is not a fallback for any language.   It results in displaying local names most of the time.

In T192701#4181938, @Nikerabbit wrote:

I think x-local and mul are less straight forward for users... is it crucial to try and change it?

I don't think it is worth changing it now. My advice would be to consider carefully in the future before introducing usages of values which do not follow the language code and language tag standards.

The idea sounds great, I am just confused about what it actually means; what conventions are we going for?

In T192701#4157564, @Nikerabbit wrote:

Adding lang="local"will force the system to ignore any requested language

Did you consider using a value that conforms to the standard mechanism to create private use language codes, such as x-local or perhaps even mul?

In T193020#4172811, @IKhitron wrote:

Hi, @Mooeypoo. If so, I suggest a second options, so the best can win. The icon will remain the same, but it will located at the left of the button, to look natural. I do not know which one is better.

In T193020#4172855, @Amire80 wrote:

The play icon is usually not reversed for RTL languages, as @Mooeypoo says.

But this does make me think:

• Why is this the icon in the first place? It has the element of movement and stopping, but it's not media. Can it be some other icon?

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

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.

In T192662#4163288, @Amire80 wrote:

Joe asked for my comments here, although I'm a bit lost, because I'm really not an OSM expert. The big thing that I fail to understand is how can it happen that some labels are not shown at all. In practice, this is indeed a regression, but isn't there supposed to be some kind of a fallback?

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 ?

In T163135#4160186, @Volker_E wrote:

@Mooeypoo I agree that option #2 doesn't sound convincing from an experience perspective.
But there are also some issues with #1:

• How do people realize that it's a MultiselectWidget when there are no items chosen yet? They come across a thing that looks like an input field with an autocomplete menu (or similar). So they choose one and suddenly the dropdown remains open. How does one close it?

The second they choose an item and the menu doesn't close, the user understands the widget allows for more items.

@Daimona can you specify briefly the behavior you described in the gerrit discussion, so @Volker_E can pitch in about maybe assessing a good general UX for the widget in these cases?

After a bit of discussion on the ticket, I've merged the code. It's a good fix for the current completely broken behavior.

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.

Aramaic is probably my fault; there are several options for Aramaic, I went with Imperial Aramaic, it might not be correct?

In T187919#4132961, @Pginer-WMF wrote:

In T187919#4131118, @Mooeypoo wrote:

That means that the hover effect is built-in OOUI for buttons, which means -- none. @Pginer-WMF if we put hover effect on these buttons, that's overriding the styleguide. @Esanders Also made a good point about OOUI's hover color being grey, not blue. What do you want done here?

The general idea is to have a list of clickable elements, which I assumed we had a standard component for, but I don't see an example in the demos. The hover color to use on lists is still an open issue, so let's use the standard to make sure it keeps aligned if it changes in the future.

In T112948#4136171, @jmatazzoni wrote:

@Amire80, thanks for checking these. It sounds like there is an issue with fonts we need to go into fully. Does this need to be a new subtask? If so, would you please write it up, since you have a good handle on the issues. Please tag it with "Collaboration-Feature-Rollouts (Collaboration-Maps)" and "Collaboration-Team-Triage (Collab-Team-This-Quarter)" Thanks!

In T187919#4132211, @Esanders wrote:

You could look into subclassing SelectWidget.

In T112948#4132011, @Yurik wrote:

Not sure if this was discussed before. Many labels in OSM are encoded with an extra param, e.g. Latn (75k), _rm (250k+), _kana, _pinyin, hira, and other. Search for "name:" for the full list. How should these be handled? I think babel used to have some support for it, but it might have been recently removed.

In T112948#4130531, @Next2u wrote:

Question: Is there a reason "round abouts" and "bus-stopps" not transliterated (e.g. in Israel)?
https://maps-beta.wmflabs.org/?lang=fr#19/31.52647/394.60170

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.

In T187919#4129260, @Pginer-WMF wrote:

• Avoid the "View more" option when there are few options. If there are 7 or less options, all of them should be listed (without a "view more" button).

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:

I implemented the hover color in the current patch. I'll poke the team about reviewing it.

In T187919#4120505, @jmatazzoni wrote:

@Mooeypoo, when and where will we be able to see this, please?

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

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.

I updated the patch, it has conditional display between save and publish now.

In T141750#4106298, @Etonkovidova wrote:

Several issues that need to be sorted here:

(1) The issue in the ticket was reported based on the dev tool Inspector displaying a large area around a marker - it's still in place (https://en.wikipedia.beta.wmflabs.org/wiki/Mavetuna - the map of Swiss):

In T141750#4104650, @SBisson wrote:

The clickable area is also too big here: https://en.wikivoyage.org/wiki/Kastellorizo#/map/0

Is it a difference between fullscreen and thumb?

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.

In T183725#4101882, @Esanders wrote:

The request in the ticket is to update language "for "publish" wikis", which would mean doubling up all your messages. I think this is the only solution that makes sense.

You may want to create the patch that adds the new messages and merge that first to give translators time to create the new messages.

@Volker_E .... could this have to do with the OOUI icon changes?

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:
https://gerrit.wikimedia.org/r/#/c/306303/6/wmf-config/InitialiseSettings.php,unified