Wed, Jan 22
Related to T240547.
Tue, Jan 21
Mon, Jan 20
Updated URLs in https://github.com/wmde/wikibase-vuejs-components/blob/master/package.json to match the current ones on Gerrit, and added https://github.com/wmde/wikibase-vuejs-components/blob/master/README.md with a link to Gerrit.
Seems done to me.
It would be lovely to have a github mirror under wikimedia for the Gerrit repo, but this is for T240224 (@Addshore if you have ideas how to expedite that one, please let me know).
https://gerrit.wikimedia.org/r/565732 has fixed it. Apologies for the inconvenience.
Thu, Jan 16
To check next: why prefetching happens, and whether it is needed - if not, should stop happening.
No problems reported for ~2 days, calling it done.
is this in "peer review" (whatever that means for the config change really), or is it blocked/waiting for the train rolling and any possible other circumstances to change?
Wed, Jan 15
@EBernhardson or some other person from Discovery would now for certain.
Quickly looking at https://wikitech.wikimedia.org/wiki/Wikidata_query_service#Data_reload_procedure, commands there mention ttl dumps though. Note that I don't really know what I am talking about, just trying to be useful.
Sounds good to me. I'd even go as far as closing this one. Whenever the need arises to have a dedicated task to do another "centralized" update/improve/whatever of the docs, let's open the new task.
Tue, Jan 14
above mentioned bug seems to be fixed now.
Wouldn't make sense to also drop https://github.com/wikimedia/wikibase-wikiba.se-deploy for symmetry?
Having briefly discussed the topic with @Samantha_Alipio_WMDE and @Lydia_Pintscher: For the time being let's continue with the limited capabilities of the non-ElasticSearch-powered search, i.e. only case sensitive exact-matching search will be provided in the environment without ElasticSearch configured.
Product Management will revisit the topic when circumstances require.
To make sure I understand the current state, is the following correct?
Data asked about here is actually pretty generic/makes sense in various projects. But given the original need came up in the Wikidata context, tagging as such.
Mon, Jan 13
This is actually causing API errors I think, see e.g. https://test.wikidata.org/w/api.php?action=wbsearchentities&search=sandbox&language=en&type=form
The task describing the issue causing this is T242415.
Fri, Jan 10
Thu, Jan 9
Thanks! I could swear I've checked the qqx version and it didn't look i18n-ed, but I must have been blind.
Closing this as done then!
@Addshore it is unclear for me from the task description whether adding a link to https://www.mediawiki.org/wiki/Wikibase/Installation/Advanced_configuration leading to the central docs place https://github.com/wikimedia/mediawiki-extensions-Wikibase/tree/master/docs is completing the task, or whether the further changes to https://www.mediawiki.org/wiki/Wikibase/Installation/Advanced_configuration wiki page is supposed to happen under the umbrella of this task?
hmm, looking at https://www.wikidata.org/wiki/Q8423?uselang=cs "datum narození" is still displayed as "600 BCE", hence it does not seem to got fixed with https://gerrit.wikimedia.org/r/538282 (which I am not sure was intent of that patch actually)
Works well, thanks @matej_suchanek !
Works after the change.
Tue, Jan 7
I feel a need to mention that, aside from possible merge conflicts, which is an argument related to pragmatics, those legacy service containers and their config should only be removed when all code paths using them have been removed. This currently is not the case. Change default config is a step in this direction, but it should become impossible for the system to reach these, which is a bit of more effort.