It's unclear to me what data the model trains on when looking at item A when claim X is removed and claim Y is added.

Wikidata's data quality seriously suffers because it currently is not possible to ping all people of big Wikiprojects to advance discussions and agree on common data modeling.

I would prefer wikitext over normal text, so that it would be "Use {{unknown value}} instead of anonymous when the author is unknown." in the example. New users might not know what "unknown value" happens to be and the wikitext template gives the user the link to the page that explains it in more detail.

Why did this happen without seeking any input from the Wikidata community? It seems very disrespectful to invalidate the solution decided on by the Wikidata community in an RFC without consulting it.

I agree that this behavior is problematic. Merging items that already have statements should not happen without the user investigating the items in question.

I don't believe that limiting it to the first 20 search results makes sense. If I have 500 search results and want to find the right one, images can be helpful to find the right one.

@MisterSynergy : The point of restrictions is that a user should not create a sitelink to a redirect without explicitly intending to do so. This was supposed to counteract the concerns that a lot of sitelinks to redirects will be created in a fashion that's problematic for Wikidata which some people in the RfC believed.

In T278962#8128218, @Lucas_Werkmeister_WMDE wrote:

What if you have a sitelink to a redirect without a badge, and you try to edit unrelated badges (add, remove or replace non-redirect badges)? Should that be allowed or prevented?

RE:request for feedback on #3:

I do think that RfC's and the Wishlist should be prioritized much higher than what happens at events and Telegram.

In T278962#7985878, @Manuel wrote:

Hi @William_Cheselden this task has a pretty high priority and will likely be tackled within the next few weeks. About your general question on why this takes so long: The main challenge is that there are so many important things to do but we have only limited development resources to actually do them. This is why we tried to get relatively small tasks (like this one) done whenever a developer has some time outside of the big sprints. Unfortunately, this hasn't always worked well and we are already thinking about making improvements to the process and making it easier to follow.

Very good. Both the interwiki bots before 2013 and 2017, and the current

"solution" requiring to trash the redirect in order to be able to connect to
WikiData have or had potential for starting conflicts or the WWIII.

@Bugreporter
If you say "we should tag" then who do you think should do the tagging? If you expect Wikipedia editors to do that, how do you think they learn that they are not supposed to put VALIDREDIRECT on redirects that are not eligible for an independent Wikidata item? If I would be a Wikipedia editor and see VALIDREDIRECT on one redirect page, my natural impression would be that VALIDREDIRECT is supposed to be put on all redirect pages that conform with the redirect policy of the Wikipedia.

Re-running the bot costs performance but not a kind of performance that matters. It doesn't increase page loading time and most of the bot activity is reading not writing so it also doesn't go produce problems with creating too many edits.

I agree that the feature should be implemented as laid out in the introduction.

The point of having 'mul' is to be able to reduce edits/per item.

There's no such thing as a fair use image. There's fair use of images but no image has a property of being a fair use image. Integrating images from other Wikipedia's this way has the potential of making some of their images uses that are currently fair use not fair use anymore because it adds uses to the images. Such a functionality would infringe on the independence of other Wikiprojects. Hosting an image for the purpose of being referenced from elsewhere is not a purpose that's protected under US fair use law.

In T285810#7185851, @Sdkb wrote:

The note at WD:Talk seems premised on the idea that I'm proposing to host fair use images on Wikidata, not just link to them. That's a misunderstanding.

I still believe that is_exception_to_constraint in the reference section would be the best way. (I create the property proposal)

mw.wikibase.getAliasesByLang would be useful, so that it's not necessary to load the whole item to access the aliases.

It would be great to have a getValidStatements() function that works the same as getAllStatements() but filters out deprecated statements. Deprecated Wikidata statements are often of no use outside of Wikidata and usecases like listing the children of a person outside of Wikidata shouldn't list deprecated children. Without a decidated function there are plenty fo cases where users will forgot to filter out deprecated statements and then show Wikipedia users data Wikidata knows to be false as valid data.

The main intention is to have Wikidata Labels and Aliases in mul.

Wikidata has lexemes in addition to items. Lexemes need language codes to express to which language a lexeme belongs. To create lexemes that tell us that vote banks is a term in en-in that corresponds to vote block in en-us we need lexemes.

The ticket looks to me more like it's about the option of filtering within Wikibase which is a slightly different concern then the filtering over at Wikipedia. At Wikipedia we have the situation that plenty of editors don't want to see Wikidata changes that don't affect Wikipedia.

The acceptance criteria doesn't specify how this feature interacts with "Show Wikidata edits in your watchlist". I assume it's bundled into that option, but it would be nice to be explicit about that.

Given that we now have the badges, I think it would make sense to automatically apply the batch when creating a sidelink to a redirect and not just allow people to create unbadged sitelinks to redirects.

I'm not sure this is the best way to frame the problem. The acceptance criteria don't cover the case where an article gets deleted but the redirect stays.

Ordering is generally useful (but can create issues as pointed out by @MichaelSchoenitzer) but it doesn't help a user to understand the concept of deprecated statements and why we have wrong data on Wikidata that we mark as deprecated.
The ordering issues could be worked out by allowing ordering to order statements with higher point in time over statements with lower point in time. I'm unsure about whether it makes sense to program a new ordering solution that only takes in account ranks but not qualifiers (and a syntax that allows Wikidata users to specify which qualify should affect the ranking in what way).

This task was opened a while ago, but stalled. I think currently, we have a consensus on Wikidata that it would be desireable to have "mul" and "mul-Latn" as languages within Wikidata.

If a bot would make this job, the bot could be able to also move the page when the item is semiprotected which would be desirable.

Given that this message is likely for many people the first time they get in contact with Wikidata it would be good to have it be friendly in addition to reciting correct facts. We might even have a "Read more" link in it to allow the recipient of the message to inform themselves better about Wikidata in case they are curious.

I'm linking to a page on OpenStreetMap.

On the copyright of maps OpenStreetMap suggests:

The constraint that it has to be symmetric would be removed by the RfC through allowing the redirect links. One those links are there it would be possible to provide additional links via a plugin to link from an English "Bonnie and Clyde" article to a German "Bonnie" and a German "Clyde" article provided there's no German "Bonnie and Clyde" article.

For non-bot users I think a limit of 15 per minute would be okay. It's a way to encourage people who make more edits to seek bot approval. I would have to stop time but in some cases, 10 might be reached by smart humans.

Scientific articles are one class of entities where this problem exists and given that they have more words in the title and we have >10 million of them they are the most important. In the past with the old search I however remember similar issues with songs and geonames derived geographic items as well.
If we would import those 2 million German companies, they would likely also produce a lot of hits.

From Lydia:

I believe we can restrict links to specific namespaces in the config. I think that would be better than an abuse filter for performance reasons. Anyone up for creating a ticket?

I'm of the opinion, that it's not our role of Wikidata to create pseudo-fake websites. In most of the relevant cases it would make sense to actually have real websites.

I'm not sure why Lydia linked to this task. If you think that the proposed check causes no performance that would be great. If it produces other performance issues it would be good to know.

Lydia linked me here. In my current draft for a living persons policy (https://www.wikidata.org/wiki/Wikidata:Living_persons_(draft)) I have a portion that suggests that for every bot edit that a bots that doesn't have a specific "living persons" flag, the bot is supposed to check whether the item is about a living person and if so check whether the property that gets added subclasses Q44597997 or Q44601380.

When people subscribe to a page that uses structured discussions they could be offered three choices:

As an example, if someone would want to write a message to my user talk page on Wikidata, https://www.wikidata.org/wiki/User_talk:ChristianKl "User_talk:ChristianKl@wikidata.org" could be used as the email address. When the sending email address is associated with a Wikidata account, a new topic on the talk page could be opened directly.

I think the necessity of having an account is comparable to the necessity to register for a mailing list to be able to post it or receive mail that currently exists. In cases where a person writes an email that isn't associated to an account they could get an automated reply telling them about the issue that requests them to resend the mail from an account that's registered to a Wikimedia account. Setting up an Wikimedia account is easy and I don't see why people without Wikimedia accounts would need the ability to post to our mailing lists.

When it comes to the limitation of "not subscribed to the thread", I don't understand the point. I would advocate a setting that creates an automatic subscription to all new threads in a given discussion page. This means if you would simply exchange a current mailing list with a discussion page a user that's subscribed gets the same email (unless he opts out).

Marking notifications automatically as read still means that you have to wade through them when you go through unread notifications. If you have page that gets >1000 links per year (many pages on Wikidata do) that's still annoying.

This would be very useful in Wikidata as new items in Wikidata usually link to others in their space and this feature allows to get notified about new items that a given user cares about.

Usecase:
There are item on Wikidata that get hundreds of thousands of links because they are used centrally. I have created items like "adopted daughter" that have less traffic but where I also don't care about every new person that's added to Wikidata that has a new statement about their adopted daughter.

I created this as wishlist item in https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Watchlists/Automatic_notification_of_new_links_to_a_page_should_be_able_to_be_activated/deactivated_on_a_per_page_basis .
It's worth noting that these kinds of notifications get created more often on Wikidata due to it being about linked data. When 10,000 notifications that Ijon gets on Hebrew Wikipedia for having created "jews" seems a lot it's nothing compared to the >1,000,000 for the person who created "scientific article" on Wikidata.

I there a reason against creating the language as mvf with the name Peripheral Mongolian?

Quora links to us with do-follow and we link to them with do-follow. In this case, I don't see a problem.

I don't see a reason why VisualEditor should be tagged. If Template is the wrong group to ping for issues about templates I'm sorry.

I created an RFC: https://www.wikidata.org/wiki/Wikidata:Requests_for_comment

@Agabi10 I don't think that's an issue in practice. Wikipedia tells a user on top of the page that they are redirected. I have created dozen's of redirects and haven't seen one getting removed.

It might be possible to simply change the https://www.wikidata.org/wiki/Template:Rfd_links template. If it's changed it might also be helpful to include the item description, P31/P279 when available, a statement count and an identifier count.

I think that this is case is the standard for property proposals and if the script could handle this case it would be a huge improvement.

It seems to me that the label is nearly always clearly stated in :

And is it really impossible to operate on the information in that in the text in which the template was inserted for the purpose of the template engine?

Okay, I think I understand the problem. It seems we would need to move the label inside the property proposal template for it to be accessible in the same way the description is accessible.

I'm also not sure what's meant with "creator of the page". There's a person who created the item. There's a person who created the article and then there's a person who added the link from the item to the article.

From a privacy standpoint, I don't see why the language of an editor should be a secret. It's valuable information that helps other users to connect with the user.

The standard way to create properties seems to be to click on "Create" in the property proposal. That automatically copies the description and the datatype.
It's supposed to also copy the property name and actually copies the name of the property proposal page into the name field (when the name isn't changed in the property proposal discussion that's usually the name that the property should have).

I'm not sure that this will reduce the amount of errors.