Sorry for the wall of text comment, some of these things are probably only relevant further down the line, but I might as well write these down now so we can refer back to this comment.

Some questions from my side, though perhaps these are going to be left for later? (I guess they all need answers before deployment):

• If the user on the client is blocked on the client, should they be able to make this edit? / should the edit link even appear?
• If the client user is blocked on the repo, should they be able to make this edit? / should the edit link even appear?
• If the client wikipage is protected, should the edit link appear?
• I guess if the repo entity is protected, then the edit link on the client perhaps should not appear?
• Should this edit link appear for anon users on the client?
• Should the users presented this edit option have some sort of user rights already?
• The data edited for wikidata will have a different license to the ones users have agreed to on the client, how will this license difference be exposed while editing?
• Do we want edit conflict detection here?

make an edit for a simple value from a client page

What are we defining as "simple value" here?
All values have some sort of validation, well parsing and then formatting is always part of the flow for values.
I guess "simple value" here means values that are currently edited on wikidata with no possible magical JS UI?
So perhaps:

• String
• External ID
• URL

No forced page reload after the edit is necessary yet

Does this mean after clicking save we want the value edited on the page to be updated?
How about if the value being edited is used in multiple different places on the page?
What do we want to happen if the user clicks save and then refreshes? I guess we want them to still see their edit.
This will probably mean once the wikidata edit has been made, force the parsercache rejection / reparse and not rely on the dispatch mechanism which could take a minute or so.

In T224833#5250530, @Addshore wrote:

Sorry for the wall of text comment, some of these things are probably only relevant further down the line, but I might as well write these down now so we can refer back to this comment.

Thanks :)

Some questions from my side, though perhaps these are going to be left for later? (I guess they all need answers before deployment):

• If the user on the client is blocked on the client, should they be able to make this edit? / should the edit link even appear?
• If the client user is blocked on the repo, should they be able to make this edit? / should the edit link even appear?
• If the client wikipage is protected, should the edit link appear?
• I guess if the repo entity is protected, then the edit link on the client perhaps should not appear?
• Should this edit link appear for anon users on the client?
• Should the users presented this edit option have some sort of user rights already?
• The data edited for wikidata will have a different license to the ones users have agreed to on the client, how will this license difference be exposed while editing?
• Do we want edit conflict detection here?

Yeah we need to address all of those but I intentionally left all of that out of this ticket because people were already saying that it is way too big as is ;-)
I have a list of things to address that overlaps with yours. I'll add your points to that and then they'll go into new tickets later.

make an edit for a simple value from a client page

What are we defining as "simple value" here?
All values have some sort of validation, well parsing and then formatting is always part of the flow for values.
I guess "simple value" here means values that are currently edited on wikidata with no possible magical JS UI?
So perhaps:

• String
• External ID
• URL

Yeah simple in this case means no suggesters, experts etc. So that boils down to the 3 you listed. I didn't take external ID because that has link formatting but I guess that would also still be ok.

No forced page reload after the edit is necessary yet

Does this mean after clicking save we want the value edited on the page to be updated?

No to keep this super simple we just make the edit to Wikidata and then the user has to reload the page to see the actual effect. (Yes shitty but since this state will not hit production that's ok as a step.)

How about if the value being edited is used in multiple different places on the page?

See above.

What do we want to happen if the user clicks save and then refreshes? I guess we want them to still see their edit.

Not sure what you mean here.

This will probably mean once the wikidata edit has been made, force the parsercache rejection / reparse and not rely on the dispatch mechanism which could take a minute or so.

Yeah we will have to see how that behaves later. For this ticket it's basically whatever :D

A problem we had with the Russian gadget is that people try to "update" information from the client instead of adding a new statement, e.g. change 2019 to 18 June 2019. In general, this isn't much of an issue for this type of edit except when the statement on Wikidata includes a reference stating "2019" and not "18 June 2019". Even a typo could be something that requires a new statement.