Wed, Aug 10
- Figure out a way to detect ES6 (using JS)
Tue, Aug 9
Mon, Aug 8
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.
Thu, Aug 4
Wed, Aug 3
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 🤦
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.
Mon, Aug 1
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
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?
Fri, Jul 29
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.
Thu, Jul 28
This now looks pretty done to me.
Wed, Jul 27
Tue, Jul 26
Mon, Jul 25
At the very least we should have another closer look now. Thank you for keeping an eye on this.
- Summary of this investigation
Thu, Jul 21
Considerations around queryable:
I looked into this a little bit, and so here is a short Addendum to the Task Breakdown Notes:
Wed, Jul 20
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:
Tue, Jul 19
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.
Fri, Jul 15
"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.
Thu, Jul 14
This now mainly waits on T297025 and more specifically T303558: Typeahead search deployment: Use CdxTypeaheadSearch in Vector
- [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