@Cparle @Mholloway while the review of https://gerrit.wikimedia.org/r/534536 is still to happen/on-going, I am wondering about the priority of this task. It's been an Unbreak Now! task for 2+ weeks, if WMDE is blocking resolution of such an important issue, we probably should stop doing so rather quick.

@Dzahn the instance was no longer in use, so I've just deleted it.

Fixed, see: https://travis-ci.org/wikimedia/mediawiki-extensions-Wikibase/builds/586014573

For what it is worth, WMF with some support from WMDE are looking into options on the graph rendering. Changes will take some time, so we need to ask you all for a bit more patience, but we're with you on that one: some solution is needed, there is not intention to just keep like it is now.

In T231729#5456584, @Lydia_Pintscher wrote:

@Jan_Dittrich @Erdinc_Ciftci_WMDE Can you please add the mockup and proposed text?

In T66315#5489251, @Ladsgroup wrote:

AFAIK, the decision was to have both for a month and then drop the toolbox.

Acceptance criteria listed in the task include "The reason of unrelated failure of the test is documented here in the task as a comment".
I don't think the explanation why/how the change made in https://gerrit.wikimedia.org/r/533956 was related to the issues noticed with browser tests.
Would you mind @Ladsgroup writing down a couple of sentences here for the future generations?

Using a packing solution on top of that is also appropriate to reduce the amount of http traffic overhead if we load these files asynchronously (which is still not supported by all browsers to this date https://caniuse.com/#feat=es6-module-dynamic-import) as well as

Closing as there is no browser test blocking Wikibase builds.

Verified to work on beta wikidata.

Verified to work on beta wikidata.

Adding a value using the language code works, but the language code is not shown, just a code. This probably requires a change outside of Wikibase software.

Adding a value using the language code works, but the language code is not shown, just a code. This probably requires a change outside of Wikibase software.

Adding a value using the language code works, but the language code is not shown, just a code. This probably requires a change outside of Wikibase software.

@Hanna_Petruschat_WMDE has discovered that apparently we've managed to not add the "fewer languages" button (vs the v1 desktop termbox)

Solved differently.

Solved differently.

@Cparle did you maybe have luck finding a reproduction path for this bug? Having stared at the code where the exception was thrown there was little hint on in which situations that might actually happen. Admittedly, this staring was rather brief.
Looking at the three example URLs, merging/redirecting seems to be involved.

git bisected to 47464abb4f2f209f4c72e8af40056f508d1a70de a.k.a. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/532334

Is this waiting for some other task to be done? Sorry for possibly asking about obvious stuff, I've lost orientation in the state of the migration.

In T222790#5439408, @Petar.petkovic wrote:

Adding new labels for Serbian is working again as it used to.

thanks @dom_walden, thanks everyone - looks it's done!

@Lydia_Pintscher said it is not worth investing effort to restore the past numbers. Closing then.

Apologies for breaking the usability of Wikidata for the Serbian audience, and thanks for reporting the issue.
The change to the ULS has now reverted, which should fix the problem for the Serbian language "variants".

In T66315#5430357, @RolandUnger wrote:

It should be mentioned that the "t-wikibase" id is not only used in style sheets but in JavaScript scripts, too. Maybe the new wb-otherproject-wikibase-item class has to be added to other style sheets.

In T207893#5431241, @dom_walden wrote:

In T207893#5429435, @dbarratt wrote:

Oversight on my part, it looks like the creation code (in both patches) is using AbstractBlock::isSitewide() instead of AbstractBlock::appliesToNamespace() (as is outlined in the task description). Using the former means that someone who is blocked from a namespace will be allowed to create an item in that namespace, using the latter will ensure they are blocked properly from that namespace.

As I understand it, the namespace blocking for Lexemes was done in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseLexeme/+/520200. But please confirm this.
Testing on beta, I cannot create a new Lexeme (either via Special:NewLexeme or api.php?action=wbeditentity) if I am partially blocked from the "Lexeme" namespace or if I am sitewide blocked.
I can if I am partially blocked but not from the Lexeme namespace.

Hi everyone. The change moving the "Wikidata item" link to another part of the sidebar has been fully rolled back after discovering the issue of the link sometimes not being visible. Now the "Wikidata link" is back to the Toolbox section of the sidebar as before.

In T230958#5430545, @LibrErli wrote:

as i mentioned above - the yesterday missing data item-link on the ui on e.g. https://de.wikisource.org/wiki/J%C3%B6ns_Jakob_Berzelius isn't the real problem. (of course, as Roland mentioned, for some items an empty edit is necessary, that the data item link is shown)
The other problem, which i discovered first in April, is a Wikisource-Page e.g. https://de.wikisource.org/wiki/Galton with existing Wikidata item with sitelink https://www.wikidata.org/wiki/Q62610504 but using the wikisource's mediawiki-api the wikibase-item is not parseable: https://de.wikisource.org/w/api.php?action=query&prop=pageprops&ppprop=wikibase_item&redirects=1&titles=Galton&format=json
as it isn't a single occurence - i will do some research for a subset of the German Wikisource and post script and results a litte bit later