Some options, as suggested:
Tue, Apr 13
Wed, Mar 31
Agreed, sounds good! Thanks :D
Tue, Mar 30
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
Mon, Mar 29
Fri, Mar 26
Thu, Mar 25
Tue, Mar 23
Wed, Mar 17
Closely related to (if not duplicate of) T276824
Mar 10 2021
Mar 8 2021
Mar 5 2021
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:
Mar 4 2021
Initial version documenting our three current APIs createad at https://www.mediawiki.org/wiki/Extension:WikiLambda/API
Mar 3 2021
Mar 1 2021
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.
Feb 25 2021
Feb 22 2021
Feb 10 2021
Current components that use wikilambda_fetch API:
Feb 2 2021
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.
Feb 1 2021
Jan 29 2021
Jan 22 2021
Jan 20 2021
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.
Jan 14 2021
Jan 13 2021
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.
Jan 12 2021
Yes! Good one! As far as I've been able to test, the fields now keep their values when the object changes :D
Jan 8 2021
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.
Jan 7 2021
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:
Jan 5 2021
@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:
Jan 4 2021
A similar component implemented in Vue by the mediasearch team to the LookupElement mentioned above is this one:
Dec 18 2020
Dec 17 2020
Submitted two patches fixing this (actually, four), hopefully I've done this alright: