Closed Bug 1246660 Opened 8 years ago Closed 5 years ago

Ongoing Localization Should be saved automatically

Categories

(support.mozilla.org :: Localization, task, P3)

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: safwan, Unassigned, NeedInfo)

References

Details

While translating any article, the content does not automatically save anywhere. So if there are any problem in the contributor browser/computer and it closed suddenly, all the work done by the localizer would be removed. Its very much frustration for the localizers. Fixing bug 619284 add a "Save draft" button, but it only saves if the localizer click on it.

Therefore, we need to save the user translation automatically. This can be on the user user browser, like localstorage.

MDN saves the translation automatically in the User Browser's localstorage. So we can follow that also.
If we would like to save on the server side, this will be also easy as bug 619284 is going to be fixed. We have an API endpoint that we can store the content in the server side as draft revision.
Topal, What do you think about this feature?
Flags: needinfo?(a.topal)
Safwan - thank you so much for looking into this!

Questions:

1. How often will the translation be saved? Every X minutes? Every X seconds?
2. How will it interact with the "Save draft" feature? Is it going to be exactly the same technically, just without clicking the button? If yes, should the button still be there?
3. What happens if I make a mistake (for example, delete a big part of my translation) and this mistake is saved locally. Will I be able to go back to the previous state? Will this impact the ctrl + Z ("undo") buffer of the text field?
(In reply to vesper from comment #2)
> Safwan - thank you so much for looking into this!
> 
> Questions:
> 
> 1. How often will the translation be saved? Every X minutes? Every X seconds?
It will be saved upon every key stroke is made. So if you type one character, it will save that instantly. So whenever your key is pressed in the translate box, the content will be saved.

> 2. How will it interact with the "Save draft" feature? Is it going to be
> exactly the same technically, just without clicking the button? If yes,
> should the button still be there?
I have thought a lot and found that, its a better way to save the auto saving content into the user browser as cache. If we do save it at our server with the "save draft feature", some contributors may have problem as it will consume much data. It will be a big trouble for the contributors who use limited Internet connection.
If we save the content in the contributors' browser, no data will be consumed. It will remain there untill the contributor press the discard button or he/she delete the cache.

The main difference between this and the save as draft feature are:
1. * This feature saves only the content
   * Save as Draft Feature saves the whole page content(like title, slug, keywords etc)

2. * This data will be saved into the contributor's browser
   * Save as draft feature data would be saved in the sumo server

3. * As the data will be saved into the contributor's browser, he can only restore it from his browser
   * Save as Draft feature data would be saved on sumo server and can be access from anywhere

4. * Only the content will be saved automatically and will be discarded automatically whenever the user press "Save as Draft" or the "Submit" button
   * All the contents including title, slug, keywords, content etc will be saved upon the contributor press the "Save as Draft" button

> 3. What happens if I make a mistake (for example, delete a big part of my
> translation) and this mistake is saved locally. Will I be able to go back to
> the previous state? Will this impact the ctrl + Z ("undo") buffer of the
> text field?

Sure, you can go back to the previous state if you press ctrl + Z. It will not have any impact on this.
Thank you for answering all my questions, Safwan. You rock!
I have some concerns about this feature as proposed, mainly around the idea of having two separate backup locations; the client and the server. It's very tricky from a UX standpoint to help users understand the two places that backups may be stored, and if they ever get out of sync from each other it becomes a nightmare to untangle what changes are right and what changes aren't.

There's existing browser addons (like Lazarus) that can save work entered into a form locally before it's submitted. There's also the draft-saving feature that's already been developed. I don't think there's a sufficient need for an extra feature here, and if there is, it should integrate with the existing draft storage feature or completely replace it, rather than live alongside it.

I'd like to hear from Kadir what his thoughts are before anyone works on this feature further.
(In reply to Michael Kelly [:mkelly,:Osmose] from comment #5)
> I have some concerns about this feature as proposed, mainly around the idea
> of having two separate backup locations; the client and the server. It's
> very tricky from a UX standpoint to help users understand the two places
> that backups may be stored, and if they ever get out of sync from each other
> it becomes a nightmare to untangle what changes are right and what changes
> aren't.

The fact is, from the user perspective, it is unknown to them. They do not know click or do anything to save the content automatically. MDN also have similar kind of feature.

> There's existing browser addons (like Lazarus) that can save work entered
> into a form locally before it's submitted. There's also the draft-saving
> feature that's already been developed. I don't think there's a sufficient
> need for an extra feature here, and if there is, it should integrate with
> the existing draft storage feature or completely replace it, rather than
> live alongside it.
>
I knew about the add-ons. But built in support is necessary as for a new localizer. As while localizing, if the browser closed suddenly, all his effort will be gone by. By implementing this feature, he can work slowly one by one.
And regarding the draft revision feature, that has another use case. if you see the bug, the concern about saving a revision as draft was "keeping the backward compatibility". That the localizer can keep localizing by maintaining the revision which is it based on. I have mentioned this in bug 619284 comment 26 about the whole work flow. 
As I have mentioned above, If we merge this autosave feature with the draft feature, it will consume much data from the localizer. will make it hard for them to keep contributing as many of them use limited bandwith Internet connection.
See Also: → 873637
Cleaning up old bugs before the migration. This has been resolved by Safwan's code (thanks!) and should not be an issue on the new platform (it includes automatic saving of created content).
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Flags: needinfo?(a.topal)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Priority: -- → P3
Hi Safwan,

Is this something the code you wrote before the migration can solve now?
Flags: needinfo?(safwan.rahman15)
(In reply to vesper from comment #8)
> Hi Safwan,
> 
> Is this something the code you wrote before the migration can solve now?

The code is ready and in the closed PR. I will discuss with giorgos if it can be merged if I reopen the pull request.
Flags: needinfo?(safwan.rahman15)
Hi Safwan,

What's the status of this request & your fix?

Thanks!
Flags: needinfo?(safwan.rahman15)
Status: REOPENED → RESOLVED
Closed: 7 years ago5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.