Some options, as suggested:

Agreed, sounds good! Thanks :D

Notice that this already happens in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikiLambda/+/refs/heads/master/resources/ext.wikilambda.edit/components/ZObjectKeyList.vue#166 and https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikiLambda/+/refs/heads/master/resources/ext.wikilambda.edit/components/ZObjectGeneric.vue#164

Closely related to (if not duplicate of) T276824

As mentioned in the closed T276356, when selecting an element in the fake dropdown, the event is not being captured and so there's no value being accepted for the component even if the input form has a valid option as value.

Closing this task, as it's a side-effect of T273564:

Initial version documenting our three current APIs createad at https://www.mediawiki.org/wiki/Extension:WikiLambda/API

With current work for T273560 the strings and references are being normalized every time we are in edit mode. Apart from this, I've removed from the ZString component the render of a link when the string matches a ZID. No link will be shown.

Current components that use wikilambda_fetch API:

Wonderful!!! Thanks, Gabriel :D

Hmm Chrome autofill might be doing that, yeah.

Probably something that the evaluator will need is some kind of health check API so that the orchestrator (or/and anything working as load balancer) can check out availability of the different language services, or the current load state of these.

Some possible improvements over current behavior can be:

• Adapt the API call to follow the Vuex store pattern: when adding an object, we can ask the store if it has the Zid information available, it will only follow through and make the API call if the Zid has not been fetched yet. The action fetchZkeys already does that, and handles the storage of both Zids and labels, so this could be used here as well.
• When a type is selected during creation, initialize it with the labels as well.
• When the type is changed, apart from adding the new labels, remove the labels that belonged to the previous type.

Marked T270295 as parent, because TypeSelector should just really be a SelectZObject component with a configuration parameter, so that it filters the types of objects to display to only ZTypes.

Yes! Good one! As far as I've been able to test, the fields now keep their values when the object changes :D

I checked jquery.i18n as suggested but I couldn't find a way to use it for our benefit. However, navigating a bit on codesearch I saw that few projects use mw.language.getFallbackLanguageChain() to get the array of the language fallback chain. I finally used this in the strategy to decide which label to display.

You are right, for the key labels it should not be necessary to request anything to wikilambda_searchlabel, although we will need it for the type/zobject selector anyway, so thanks!!

One fast way to reproduce the error should be:

@Jdforrester-WMF I am using wikilambda_searchlabels to get the labels in the user defined language, but somehow the language fallback doesn't seem to be working for me. For example:

A similar component implemented in Vue by the mediasearch team to the LookupElement mentioned above is this one:

Submitted two patches fixing this (actually, four), hopefully I've done this alright:

• For ZKey https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/650150
• For TypeSelector https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/650164