1. Figure out a way to detect ES6 (using JS)

In T309872#8134065, @Jdforrester-WMF wrote:

OK, this is now done from the gerrit/etc. side. If you think all Phabricator tasks are closed, we can call this Resolved.

FTR: I'm not sure what the status of this is, but the repository that made us open this ticket is now being archived: T309872: Archive wikibase-vuejs-components library repository.

In T309872#8134065, @Jdforrester-WMF wrote:

OK, this is now done from the gerrit/etc. side. If you think all Phabricator tasks are closed, we can call this Resolved.

Glancing at the repository, I'm not sure if there is anything that you need from us to migrate wikibase/termbox on Wikidata? Though I'm not very familiar with this particular part of our code base, so there might quite likely be something that I'm missing.

Thank you. I'll look into that both termbox and vuejs-components are on our radar with the right priorities.

Almost done. We still need to update the CONTRIBUTING.md, which is the last mention of Travis in this repository, and then this task can be closed.

Thank you 🙏

Disregard my above comment, this is still relevant. This is about wikimedia-ui-base, not wikibase-vuejs-components 🤦

In T268108#8127010, @Aklapper wrote:

Should this task (and subtasks) remain open given T309872: Archive wikibase-vuejs-components library repository?

This was done in 740656: bridge: reintegrate wikibase-vuejs-components for T294465

(I created this task mainly so that we have something to point to as the blocker for T314468)

This is currently blocked on T314470: Upgrade all CI jobs for WMF-deployed projects from Node 14 to Node 16, otherwise it fails in CI.

In T279421#8119828, @AnneT wrote:

Clarify and organize the various phab boards, and indicate which are deprecated. We have WVUI, Vue.js, Codex, Design-Systems-Team; scope of Phab project tags feels unclear. Please clarify the Phabricator project descriptions to shed more light on this.

IMO, this has been completed, although I welcome feedback from anyone who has suggestions for making things clearer.

WVUI has been marked as deprecated and it is noted that it will be replaced with Codex. We can mark the tag as inactive once WVUI is removed from MediaWiki and no longer in use.
Vue.js is described as a general tag for Vue.js work, which is in line with the way it's currently being used.
Codex and Design-Systems-Team are described in-depth both on our team page and on the Codex docs site.

One strong contender for our work would be T306932: Add configurable scroll behavior to the Menu component, which would directly benefit the search on the new Vector skin on Wikidata

In T313466#8118981, @Lucas_Werkmeister_WMDE wrote:

So is that a warning in Wikit terms? (storybook)

After the merge of 758961: Search: Use Codex and Vue 3 instead of WVUI and Vue 2 and the train running, we were expecting the search on Wikidata.org with the new skin to be broken. However, this is not the case, we are still seeing the Wikibase workaround/replacement. Can you confirm that this was intentionally done in order to prevent Wikidata.org to be broken with Vector-2022?

I realize that this might be a bit late to bring it up, but are we sure that we want that warning to be only yet another paragraph in the intro, like on the old page?

There is the extension https://github.com/ProfessionalWiki/AutomatedValues that ironically allows defining rules for automatic setting of labels and aliases based on statements. Could be worth a look nonetheless.

@Manuel I think adding another BDD is the better approach here, because that emphasizes that we need to explicitly test for it.

This now looks pretty done to me.

In T313945#8109693, @egardner wrote:

@Michael I understand you spent some time exploring how to use Vue.js-based gadgets. Would love to learn about any of your findings here – are there other things that need to be done to better support gadget authors which are not on the list up above?

At the very least we should have another closer look now. Thank you for keeping an eye on this.

1. Summary of this investigation

Implementation note:

Considerations around queryable:

I looked into this a little bit, and so here is a short Addendum to the Task Breakdown Notes:

Mh, this will be a bit tricky, because the font-family in very easy to override as its specificity is almost as low as possible:

Inconsistencies around denotable:

• EntityIdSearchHelper, created in context of \Wikibase\Lib\EntityTypeDefinitions::ENTITY_SEARCH_CALLBACK depends internally on Terms even though the concept of Entity itself does not.

[WIP]
"user abilities" related to denotable

Overall, addressable seems to be rather straight-forward by implementing the datatypes callbacks and hooking into the Wikibase*DataTypes hooks. This would still leave queryable open, but I will have to spend dedicated time on that, because I have so far no clue about how triple storage and RDF-dumps work.

@noarave took care of this in #238 in the context of T311231.

This now mainly waits on T297025 and more specifically T303558: Typeahead search deployment: Use CdxTypeaheadSearch in Vector

1. [WIP] List of ways extensions could integrate with Wikibase functionality in principle

This still needs data for the newly created Lexemes per day.

The page is now available on www.wikidata.org and so we have some early data and can now create the boards

In T312658#8068853, @Lucas_Werkmeister_WMDE wrote:

In T312658#8068781, @Lucas_Werkmeister_WMDE wrote:

The search results for merged items will only show the item ID, though, and I think this would be pretty hard to change:

Hm, nevermind – if we use the new FallbackLabelDescriptionLookupFactory in the ENTITY_SEARCH_CALLBACK entity type wiring (which would be part of T312223), then wbsearchentities starts returning labels for search results that belong to redirected items. (Though I’m pretty sure it doesn’t affect which items get returned in the first place, and that redirected items are only returned if you search for their item ID.) Is that something we want or not?