Last modified: 2014-05-03 09:03:44 UTC
When I encountered https://meta.wikimedia.org/w/index.php?title=Global_bans/it&diff=prev&oldid=5797957 -- a piece of pretty routine minor vandalism -- I was unable to use Undo to remove it. Instead, I had to go find the text in the translation interface and then manually edit it out as a new revision. Avoiding this kind of slower workflow for removing vandalism is why we created tools like Undo and Rollback. I fully understand the need to drive new translation activity to the translate interface. But plain revert/undo actions should be supported still IMO.
Undo and rollback works, but you have to find out the edit to the translation unit instead of the secondary edit which updates the translation page. Those edits are hidden by default in recent changes, but you can show them or check the user's contributions. It would be technically complex for multiple reasons to support the scenario that reverting change to the translation page would revert the original edit: * the unit edit can be a new page, while the translation page edit is just a normal edit. * we would need to hook into and override the normal undo and rollback actions - I haven't checked whether suitable hooks exist. The other way is easy and works already, except that deleting a unit translation does not currently trigger regeneration of the translation page.
(In reply to comment #1) > Undo and rollback works, but you have to find out the edit to the translation > unit instead of the secondary edit which updates the translation page. Those > edits are hidden by default in recent changes, but you can show them or check > the user's contributions. This is too complex for the average user, who just sees a piece of vandalism and expects that the (undo) or rollback function works as usual on a wiki page.
(Re-fix terminology in summary.)
To revert a new unit created by a vandal inserting spam text, deleting it requires administrator rights. But you can edit it and replace the spam text entirely with "!!FUZZY!!" and nothing else. The translate tool however should not count any unit which is currently only "!!FUZZY!!" as a fuzzy one, but as a non-translated one, as it was before the vandal created the new version with spam or random text (random text, typically a single character, may be inserted by error because of an unexpected keystroke in the textarea. More generally every action you can make on a regular page should be possible in the Translate tool when selecting a unit from the list on units, directly in the edit form. This includes the possibilty of previewing it. Note that we can close the edit interface by keeping edits unsaved, but without canceling it: this allows visiting other units to copy/past some parts and return to the edited unit: * the background color in the preview shoudl turn to light red, showing in the list that the edit was still not "Saved" or "Cancelled". * If we cancel out own changes, the text is revereted to the saved version, and the background color in the list turns back to white, or yellow (!!FUZZY!!) * IF we attempt to navigate to another URL, we'll see the alert box saying that there are unsaved edits that could be lost. * The same background in light red color would be used if a save action failed for any reason (e.g. database is locked, or edit conflict, or server not responding, or network problem, or loss of session, or mismatching value page-edit cookie, or expiration of user's logon cookie, or change of status of the user, such as the user being blocked for abuse/vandalims). In other words: make sure that each unit behaves like a regular page, except that everytging in the Transalte page is like a "decoration" around the edited unit.
We already highlight unsaved translations and give warnings if those are present when navigating away.
