How do you make sure then you are not adding a statement that is already there?

Yes, I also think one should add a statement to the regarding section.
It seems to me more that the TOC or some other in page navigation is missing and that solving this would also satisfy the need described here.

In T142082#2623859, @Lydia_Pintscher wrote:

How do you make sure then you are not adding a statement that is already there?

I don't understand the question. How does a button at the bottom not have the same problem?

I don't get the point of scrolling either. Pages are getting annoyingly long and frequently I add statements that I know aren't there because query.wikidata.org found the items.

In general, I think we urgently need more compact views: depending on the purpose, frequently entire groups of statements are irrelevant for the task at hand and could easily be collapsed or replaced a simple count. Imagine if every item had tons of ELO ratings ;)

Can we add this to T150179 ?

Let's not add easy tags to tasks that don't have consensus. It'd just lead to newbies being burned by rejecting their code.

Users seem to need it and my lay view is that it shouldn't be too complicated too do. I might be mistaken about the later.

It's not really clear why adding twice the same statement is much of an issue (other than for the user).

In T142082#2910992, @Lydia_Pintscher wrote:

Let's not add easy tags to tasks that don't have consensus.

This task has consensus. Not a single person raised objections.

I have raised objections several times when this came up on-wiki.

We could have a keyboard shortcut that power users could use to trigger the add button.

Agreed.

Then there is the question which shortcut!
Alt A ?

There's T146205 for a keyboard shortcut, btw. The "KeyShortcuts" gadget (which I use) uses just "a", so alt-a would be fairly consistent with that and would probably be usable in situations where the KeyShortcuts gadget isn't (e.g. when text fields or links are focused).

I'm not interested in a shortcut, please file a separate task for this supposed need of power users. This task is about how to make it easier for users to add new statements, especially inexperienced users who may not be versed in exactly calibrating their scrolling to find the randomly-positioned button.

In T142082#2912867, @Lydia_Pintscher wrote:

I have raised objections several times when this came up on-wiki.

Where? I could not find any such discussion and we still don't know what objections you have.

In T142082#2912867, @Lydia_Pintscher wrote:

I have raised objections several times when this came up on-wiki.

Where? I could not find any such discussion and we still don't know what objections you have.

I don't recall that either. Why isn't it being linked from this thread?

@Lydia_Pintscher for the sake of clear communication and to avoid mixing roles, you might simply want to decline this request. Otherwise someone does write the code and it ends up getting rejected, "easy" tag or not.

I have not declined it yet because there clearly is an issue we need to solve. I just object to the proposed solution.
My objection is that just adding another button clutters the user interface more (while we've been trying to clean it up) and if it is at the top it will encourage newcomers to not look at existing statements before adding one.

Maybe you could just include a text about that in the warning that already appears to first time users.

Obviously anything can be see as cluttering the interface, but the priority is to have statements added ..

If an additional button adds clutter, I propose to remove the button at the bottom.

I agree that the current "add" buttons at the bottom are hard to find on large pages, and I have seen this put off newbies.
Replacing them with one predictably located bottom on the top sounds like progress to me.

Checking for existing statements with essentially the same information can be quite daunting already for human users (example: https://www.wikidata.org/wiki/Q13561329#P682 ) and should perhaps rather be done automatically before saving - we already have similar mechanisms in place to check whether two items share the same label and description in the given language.

Note that the relevant “ add” button is quite hard to find — you are looking for the one right at the end of the list of existing statements

https://medium.com/mysociety-for-coders/help-us-find-the-offices-of-heads-of-governments-across-the-world-4558124bcd24

Maybe it's time to rise the priority of this.

Such feature should consider page layout for lexemes. There is many "add statement" buttons for lexeme, every sense and every form. Single button at the top could be misleading which "add statement" it duplicates.

In T142082#2913501, @Lydia_Pintscher wrote:

I have not declined it yet because there clearly is an issue we need to solve. I just object to the proposed solution.
My objection is that just adding another button clutters the user interface more (while we've been trying to clean it up) and if it is at the top it will encourage newcomers to not look at existing statements before adding one.

I dont look at existing statements even now when the button is at bottom, especially if the item has way too many statements. Never bothered checking. It shouldnt be something users fulfil but the server/website should do automatically.

In T142082#3318017, @Daniel_Mietchen wrote:

I agree that the current "add" buttons at the bottom are hard to find on large pages, and I have seen this put off newbies.
Replacing them with one predictably located bottom on the top sounds like progress to me.

Checking for existing statements with essentially the same information can be quite daunting already for human users (example: https://www.wikidata.org/wiki/Q13561329#P682 ) and should perhaps rather be done automatically before saving - we already have similar mechanisms in place to check whether two items share the same label and description in the given language.

Agreed with every single word of Mietchen's.

I'd imagine an interface, where as I type it suggests properties, like IDE suggesting variables/commands. I choose the one I want to edit, and it shows me any values it has right now.

Copying remarks from Wikidatadiscussion (https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team&oldid=1153153934#Adding_statements:_please_add_an_'add_statement'_possibility_on_the_top_side_of_the_page_also):

The main blocking point seems to be that adding a button at the top of the sections would encourage people to add statements without checking if a similar statement is already there.
:If you really want to have this button, I guess a userscript could work. I'm pretty sure it already exists but I couldn't find it, maybe someone can point it here? [[User:Lea Lacroix (WMDE)|Lea Lacroix (WMDE)]] ([[User talk:Lea Lacroix (WMDE)|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]])

::Thank you for answering and bringing the request over to Phabricator. In my case, I often come right from Commons to add an image, knowing from the Wikidata Infobox already that an image statement is not already there. And as someone else mentioned: the same possible problem would still be there when people jump right to the bottom (by keyboard End button) to find the statement button they need. I'm not sure what you mean by a userscript, but it was already suggested to me to use [https://tools.wmflabs.org/quickstatements/#/batch quickstatements], which doesn't seem comfortable, and also to use [https://www.wikidata.org/wiki/Wikidata:Tools/Enhance_user_interface#KeyShortcuts KeyShortcuts], which is hardly an improvement over using the End button, which besides from still requiring hand movement from mouse to keyboard also seems to favor editing the label, not creating a new statement. Unless discussion is continued here, I will further comment on Phabricator. Thanks again, [[User:Eissink|Eissink]] ([[User talk:Eissink|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 17:08, 8 April 2020 (UTC).

In T142082#2623859, @Lydia_Pintscher wrote:

How do you make sure then you are not adding a statement that is already there?

by software? Can you check, whether the statement is already there and issue a confirmation message, if so?
By placing the add button at the bottom, you can make sure neither. I use the scroll to end button, I read what I want and not what you want me to read.

The issue is that the button is not at the bottom, actually it is above sitelinks and above external identificators. It is even hard to find it. I agree with @Herzi.Pinki, this should be handled by the add dialog window.

In T142082#6065221, @Dvorapa wrote:

The issue is that the button is not at the bottom, actually it is above sitelinks and above external identificators. It is even hard to find it. I agree with @Herzi.Pinki, this should be handled by the add dialog window.

@Dvorapa, it depends on the size of the window. sitelinks on large windows sometimes do appear on the right side, not on the bottom. So another annoying point, that the sitelinks are in different places depending on the window size.

I'll copy the answer I provided on the "contact the development team" page:

We understand that the "add a statement" link at the top of the page is a valuable feature that would make the life of many editors easier. I also agree with you that the choice we previously made to not have this feature in order to avoid creation of duplicate statements is not a proper solution to the problem. It enforces a certain behaviour on users (scroll to read all statements), when we should instead make sure that the software is dealing with possible duplicates correctly. This choice was an acceptable solution at the beginning of Wikidata's development, but not anymore.

Here's what we can offer now to move forward: we can work on the implementation of the "add Statement" button at the top of the page, as soon as possible (it will be tracked in the existing ticket). In parallel, we will start investigating on a proper way to check if the editor is about to create a statement that already exists, and to inform them before saving the statement. I created T250993 for this task.

I added as subscriber.

• The workflow to manually create Wikidata Properties for entries with more than 10 Properties is weird and slow.
• The "solution" to place the button in an awkward position to "prevent duplication" is offending.
• The "solution" to place the button in an awkward position will NOT prevent duplication. Everyone is using the "end" button. Or enable "KeyShortcuts" and press A
• The actual issue of the missing Database constraints preventing duplication on Database side is UNRELATED.
• This ticket was opened in 2016. In 2020 it looked like @Lea_Lacroix_WMDE understood the issue, but then it was connected to the unrelated issue again.