One other thing about this patch – this is a breaking API change so we'll need to make sure the Android team knows about this and has time to prepare a patch for compatibility before we merge. @Ramsey-WMF or @CBogen can you ensure that they get a heads up about this? We don't version our APIs in the traditional way here as far as I understand, but is there anything else we need to do before changing the response of a public endpoint in the way we're considering here?

I'm willing to take a stab at the "simple" implementation here, but will probably need some code review assistance again.

It looks like labels and descriptions could be handled the same way in terms of language fallback chains, but aliases might need to be treated differently – namely, just don't display them at all if we can't find one for the current language. @Ramsey-WMF does that sound right to you?

I'm willing to take a stab at this, as it should be pretty straightforward and I'd like to learn more about how to work with API endpoints in MediaWiki PHP. @Mholloway would it be okay to add you as a reviewer to any patches I submit here?

The new designs will require some additional data (mainly: descriptions/aliases for each tag being displayed). We've also just added the ability to display the categories a File belongs to, which required a new API request from the client.

That screenshot is showing incorrect behavior at the Qualifier level. Just uploaded a 1-line patch which should address that by simply wrapping the qualifier value in <bdi> tags, like we do for Items. Let's get this on Beta quickly and check the same file again.

So I think things are working fine at the level of the ItemWidget. Here's the markup for Item labels as currently deployed on production:

It seems like the problem is that Echo doesn't really have a way to know that multiple events generated on the server at different times (as part of a job queue, for example) should be consolidated.

I think a tag is good for now; later on we can organize things into projects as needed. It will be helpful to have a window into Vue-related development happening across teams.

@Catrope This is not urgent, but it would be nice to have a resource module for Vuex in core that works similar to the one for Vue itself. Right now I'm including the Vuex code in a vendor subfolder but other projects will presumably need to use this soon as well.

@Ramsey-WMF just posted a new patch for this. Here's the new behavior if the user tries to change a previously-valid qualifier to an invalid one:

Here's the updated coordinate input in Hebrew:

I believe that this is a matter of hard-coding the dir=ltr attribute (or doing the equivalent in CSS) on the actual coordinate input & display elements – the idea is that we don't want the letters/numbers getting shuffled around in lat/lng strings because then they become nonsensical, even when the rest of the text needs to change.

This looks like a situation where we need to apply a different label (or simply show no label at all) in the second disabled field before the user has specified a property in the first field. I propose we handle this situation like so:

I stepped away from this discussion for a moment, but I wanted to say thanks to everyone for all the thoughtful contributions. And a special thanks to @EvanYou for engaging with us here, it's really great to have his perspective as the creator of the framework under discussion! Thanks for sharing some information about how the Vue team is managing the introduction of new features and project sustainability.

This should be addressed by this patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/574603

Just submitted a patch that removes the "primary" class from the "Add" button in the String, Quantity, and GlobeCoordinate input widgets. Here's an example of how it looks just as a "progressive" button, in a QuantityInputWidget:

@AronManning I think a tool like MMV is exactly the kind of thing that could really benefit from a Vue.js re-write. The UploadWizard tool is another.

We will definitely need to study any possible performance impacts from using the template compiler at runtime. If it turns out that relying on the compiler at runtime causes significant perf regressions then we will need to come up with another solution (and re-open some points in this discussion).

@dbarratt regarding need for a build step: there's some discussion of this in the original RFC; it's true that React can be used sans build-step with the CreateElement API.

I wanted to join in this discussion earlier, but I spent the last two weeks fighting off the flu. Thanks to everyone who has participated so far, it's great to see interest in this topic. I'd like to try and speak to a few points that have been raised so far. I'll paraphrase some of the questions I've seen upthread:

Thanks for the feedback about real-world use-cases here, it's useful.

@AnneT this was bugging me a little bit too. The problem is that ItemWidgets appear directly beneath their statement input widget in all other cases. If the map is part of the ItemWidget, it will appear flush with the input (leading to confusion about which map relates to which element).

One thing we should keep in mind is how the proposed changes here would impact the "copy to all" functionality.

@kchapman I assume that after Last Call, there is some kind of official vote on whether or not to adopt a given proposal – is this correct?

Here are some new screenshots representing the approach described above:

In that case, I think the best way forward would be to introduce this functionality in a new patch that builds on top of the two previous ones. I can start on that tomorrow.

Right now I can think of two ways to try to support the use-case you are describing (make it easier for the user to visually see previously-entered coordinates on a map):

@Ramsey-WMF we don't currently support a lot of edit-in-place functionality anywhere in the SDC UI – users are encouraged to just add new values or delete old ones. Compare with cases where a string or URL field is entered – if a user sees a typo in a URL, they can't just edit that value; they need to delete the old one and add a new one. I think that this is all a legacy around the initial designs assuming item-types and dropdown inputs everywhere. (Qualifiers do allow edit-in-place functionality however – so we are inconsistent in our inconsistencies).

Ok, I've updated the design a bit of the expanded/collapsed map. Here are some new screenshots:

I'm in agreement with @matthiasmullie that the map is very prominent by default, probably too much so. It will also cause a bunch of image tiles to be loaded which is a consideration for bandwidth.

@Ramsey-WMF if you want, we can merge the first patch (that enables the map feature at all) and then wait to merge the second one (which hides it by default and consolidates the input fields to a single row), adding further tweaks if necessary.

@Ramsey-WMF the map itself works OK on mobile, but we could probably stack the compact row elements a little more nicely. I'll take a stab at that next.

Hi @SBisson, I agree that this would be a useful feature. I'm happy to turn this ticket into a formal request (not sure if there are any tags that I should add for that).

There are currently two patches which are ready or near-ready that address this issue. Currently the UX for "enhanced" coordinate input looks like this:

Don't worry, nothing is obvious as far as I'm concerned. This is my first attempt using Echo (most of my work is on the JS side).

In the short term, we may disable the email notifications entirely – it's likely that very few users have opted-in to this in the first place.

@Ramsey-WMF I'm able to reproduce this locally, but I don't understand why email notifications are not bundling; I've followed the instructions in the Echo docs but I must be missing something. I'm pinging the Notifications project and @Catrope in the hope that they can shed some light.