alaa_wmde added a comment.
I'm adding another motivation for saving in one http request instead of separate ones, that is device-independent. (copy-paste a previous comment https://phabricator.wikimedia.org/T212869#5135995) > 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 before now, 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, that if they even 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/T220696 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: alaa_wmde Cc: alaa_wmde, Lucas_Werkmeister_WMDE, Lydia_Pintscher, Aklapper, Lea_WMDE, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Jonas, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
