In T235152#5575023, @Lucas_Werkmeister_WMDE wrote:

In fact, it looks like this is exactly what mw-editable was added for?

Yes. But do Wikibase installation owners and technical people know how to escalate those issues? I think they're escalating them but through private channels, which implies that, if the problem is theirs, the next user with the same problem doesn't find anything in a web search or in the documentation and asks again; and, if the bug is in the software, it is sometimes forgotten or bypassed, or even the user decides to change the use case, before the bug translates into a Phabricator task.

The status is automatically given by the software after carrying out some edits. By "care about Wikidata" people usually mean learning what Wikidata is about by carrying out those edits. In that case (the usual), the flag request is unnecessary.
(By the way, we can consider lowering the threshold of the number of edits if we conclude that it's too high, although it was actually increased a few years ago for the opposite reason; I was not involved in the process and, honestly, I don't remember what that threshold is right now.)

In T213300#5565206, @Uzume wrote:

I do not think this is a good idea. This amounts to security through obscurity and in general is not a good practice. The same data could be found in a number of other ways (e.g., api.php which would be even more useful to a potential vandal bot) and in the end does nothing to actually prevent any vandalism to begin with (just attempts to deter it by obscuring which pages have the most links). Also unconfirmed users (e.g., anonymous IPs) might have valid reasons to what to know which pages are most linked. We already punish such editors enough for the faults of troublemakers. I do not see this as a great way to protect our content from vandalism and it definitely punishes other users.

These pages should likely already be well known to administrators that will have added protections to them and obscuring which pages they are adds little.

Usually editors have two opposite views about this option. One is similar to what @Amire80 exposes: if we propagate the autoconfirmed statuses from Wikipedias to Wikidata, then these autoconfirmed users are free to work on their wikis autonomously, without having to care about Wikidata. The other view is that they should actually care about Wikidata, that the confirmed status is easy to get and that you already get it automatically after carrying out the few test edits necessary to know what Wikidata is about. Some people will say the first option pursues our goals and contributes more to centralization/harmonization, and others will say exactly the same about the second option.

I want to thank you for finally solving this task. It's a great idea for users to generate content collaboratively and horizontally, but this model doesn't favor process efficiency, user experience or innovation, so these areas require skilled professionals who fight against tradition, stagnation, short term and subjectivity. Users hardly ever like change, but I do think the improvement is significant and right now I don't miss anything from the old version. Keep up the good work! :-)

In T229100#5551887, @Lydia_Pintscher wrote:

@abian can you clarify what you mean with the acceptance criteria?

Okay! But I'd need some help to know what/where to touch. To set HTTP headers for the Special:EntityData pages I would probably change /repo/includes/LinkedData/EntityDataRequestHandler.php, but what should I touch if I want to set HTTP headers for the wiki pages (not necessarily loading them through Special:EntityData)?

Thanks for the task, @Lucas_Werkmeister_WMDE!

Thank you both! :-)

Thanks for all the work! I have a question: what dimensions of data quality (completeness, accuracy, consistency...) are you guys considering when you speak of "quality" in this scope? The term "quality" is a buzzword used by people to name things that sometimes have no relationship to each other, so I'm not sure what it means here in practical terms, I don't know what factors are included in the equation (and which are excluded and should be measured separately).

Any thoughts on this?

Hopefully these needs will soon be met by https://etl.linkedpipes.com/ and OpenRefine has also added some features and improved its integration with Wikidata.

This was fixed a long time ago. Thanks!

Thanks! :D

Thanks! Is this fixed now that wikibugs is online?

My usual behavior is (and surely will be) to open these kinds of links in new tabs even if they don't have a target="_blank". Which doesn't necessarily mean my behavior is perfect, of course. :-)

The highlighting of statement groups ("properties") is now available on Wikidata. The highlighting of individual statements still needs approval on Gerrit.

In T178745#5459066, @Lucas_Werkmeister_WMDE wrote:

What’s volatile about them? We’ve preserved the capitalization of q1$21f31f42-4f4d-79b0-0380-92039776e884 for a long time, for example (notice how the entity ID is in lowercase).

In T178745#5458939, @Lucas_Werkmeister_WMDE wrote:

In my opinion it would also be nice to make this work for individual statements, e. g. not only https://www.wikidata.org/wiki/Q1#P793 but also https://www.wikidata.org/wiki/Q1#Q1$e70e289c-471e-36b8-50ff-25612cf24e70. As far as I can tell, the above patch doesn’t implement that.

Solved?

This is not an issue in EntitySchema but in Wikidata's title blacklist. I will try to fix the regex now.

I think the chain of redirects isn't correct now. When I load /ontology with HTTPS there's a redirect that takes me to a HTTP page, and then another redirect switches to HTTPS again.
https://wikiba.se/ontology → http://wikiba.se/ontology-1.0.owl → https://wikiba.se/ontology-1.0.owl

In T155359#5415537, @MasinAlDujailiWMDE wrote:

@abian Ah, I didn't configure www.wikiba.se. Now I ran into Let's Encrypt rate limiting because I didn't know how to properly configure multiple nginx server names with puppet. I will try again in an hour, but then it should be complete.

How can we help?

https://tools.wmflabs.org/status/#wikiba.se :D

When requesting data via the Accept HTTP header at least the following values are supported: application/json, application/vnd.php.serialized, text/n3, text/rdf+n3, text/turtle, application/x-turtle, application/n-triples, text/n-triples, text/plain, application/rdf+xml, application/xml, text/xml, application/ld+json. These values are just aliases (redirects) to the URLs with the extensions, some of these values are duplicates, and some of them (e.g., text/rdf+n3) aren't media types recognized by the IANA either, but I do think these redirects are useful and guess they don't significantly increase the maintenance cost. In particular, redirecting some extensions to others might be simpler and more maintainable than what is done for header values, and in that case I would wonder why not give back to users what they want when we know unambiguously what it is.

Hey, thanks for the reference! I didn't know that task was open. But both tasks aren't exactly the same, this task is oriented to generate wikilinks automatically from every single entity ID that doesn't have an explicit link in the raw text. For example...

@Groceryheist, please feel free to tell us in case we can help you in some way. :-)

In T222861#5169845, @Lucas_Werkmeister_WMDE wrote:

We could define three new predicates to link statements to constraints only if the constraint status matches that predicate, either in addition to the existing wikibase:hasViolationForConstraint predicate (which would continue to link statements to constraints for violations of any status), or replacing it (though this would break existing queries).

I’m struggling to find a good name for the middle predicate, though, because I don’t think we have a good name for the default status. The items are “mandatory constraint”, (none) and “suggestion constraint”; internally, the statuses are violation, warning and suggestion, but if we use violation directly that collides with the existing predicate.

wikibase:has{MandatoryViolation,Warning,Suggestion}ForConstraint would work, but feels odd to me. Thoughts?

@JAllemandou, do you think this is now unblocked?