alaa_wmde added a comment.

  Sorry to come late to this one. I can still see one problem here even if we 
find a way to tell the second request to look at the right revision id.
  
  The problem comes from the fact that UI is making two separate requests for 
what appears to be an atomic action (save all changed terms) to the editor. 
While that haven't caused any issues, and probably was decided to be done that 
way so that changing labels, descriptions and aliases get their own edit 
revisions separate from each other (for easier rollbacks and more atomic 
history on level of term edits), bubbling up this kind of separation up to the 
UI is problematic in this case.
  
  **Why is that a problem now?**
  Let's assume that second request (description in this case) is "fixed" and 
will look at the parent revision id instead of baserevid and it will detect the 
duplication correctly and fail.
  In that case, the label will be changed, but the description will not, which 
is not the right thing to do here from UX perspective. The editor is editing 
both, and press `save` expecting both to be saved or nothing to be saved if 
they did a mistake or didn't know they can't use same label and description. 
Their next step will be to go and rollback their edit to the label, given they 
actually noticed that it was saved after they get an error message (due to the 
failing second request)
  
  **How to solve UX issue?**
  If that part of editing does not work without javascript anyway, we can add 
some client-side validation. If not, then we have to do one request for saving 
(can we use wbeditentity endpoint instead for instance?).

TASK DETAIL
  https://phabricator.wikimedia.org/T212869

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Greta_Doci_WMDE, alaa_wmde
Cc: hoo, Lucas_Werkmeister_WMDE, alaa_wmde, abian, Aklapper, joker88john, 
CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, 
Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, 
Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, 
QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, 
Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to