Last modified: 2013-03-31 15:04:38 UTC
I came across this when setting up a test scenario for page translation on test.wikipedia.org. When a translation is being saved, the editor is opened, the translation is changed and saved again, that change will not be stored, but only the initially submitted value will be stored in the wiki. The below steps to reproduce require a backend that does not respond "instantly", because that makes it very hard to reproduce. It should take a few seconds before the status changes from "Saving..." to "Saved", otherwise the scenario cannot be run. Steps to reproduce: 1. Open URL while logged in to https://test.wikipedia.org. 2. Open and edit any message. 3. Click save. Observed: I: "Saving..." is displayed. II: After some time, this changes to "Saved" 4. Repeat steps 1-3, but immediately repeat the steps again. Observed: III: After some time, the change from 2 is displayed. 5. Refresh the page Observed: IV: The change from 2 is displayed. Expected: V: The change from 4 is displayed. I cannot reproduce this consistently because of timing issues, I presume. Rapidly editing the same translatable unit can lead to weirdness. Not sure if and how this could/should be resolved, but at least it's documented now...
Doesn't this probably depend on bug 45894 or related?
(In reply to comment #1) > Doesn't this probably depend on bug 45894 or related? No.
This is because of ajax calls returning in random order. Trying to solve this by avoiding parallel save requests from a message item - Disable save button till previous save is done - Patch If3e85bb64109ed2c2f577f2cc67cd3e4e03e59b4