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.

swalling wrote:

(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.

Would it be feasible to just change the target of the undo link to redirect somewhere else? Specifically, here's what I had in mind:

1. If the translation unit was updated from an older version, then link to the undo for that translation unit edit. This is pretty obvious.
2. If the translation unit was newly created: If the user has delete rights, link to action=delete for that translation unit. If the user does not have delete rights, then ??? (maybe link to action=edit for the translation unit, so they can tag it for deletion or whatever)