Last modified: 2013-03-31 15:04:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T48567, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 46567 - [TUX] Correcting a "Saving..." translation and saving again discards the correction
[TUX] Correcting a "Saving..." translation and saving again discards the corr...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Translate (Other open bugs)
master
All All
: Low minor (vote)
: ---
Assigned To: Santhosh Thottingal
https://test.wikipedia.org/w/index.ph...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-26 15:14 UTC by Siebrand Mazeland
Modified: 2013-03-31 15:04 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Siebrand Mazeland 2013-03-26 15:14:42 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...
Comment 1 Nemo 2013-03-26 15:28:26 UTC
Doesn't this probably depend on bug 45894 or related?
Comment 2 Siebrand Mazeland 2013-03-26 18:59:20 UTC
(In reply to comment #1)
> Doesn't this probably depend on bug 45894 or related?

No.
Comment 3 Santhosh Thottingal 2013-03-29 08:42:00 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links