1088724 - [translate] Real time translation updates

Status: RESOLVED MOVED

(Webtools Graveyard :: Pontoon, defect, P3)

Description

[Matjaz Horvat [:mathjazz]]

If multiple localizers are working on the same project/resource, they should see translation updates right after they are submitted to avoid duplicating work.

Comment 1

[sandra.shklyaeva]

Because of the ticket regarding the offline mode, I am also very concerned about the problem with the mess that can appear during translation by multiple localizers. So, I decided to accept this task too.

If we do not want to leave ajax behind and start to use websockets (if we want, let me know. I'm in! :)), we cannot get true real time notifications.

As far as I can see, we have two options:
 - send a request for all available translation updates every X seconds/minutes. It looks inappropriate for me in the context of this task. Let me know if you think otherwise.
 - check for updates for particular entity before adding new translation for it
  - if we have no updates, add new translation as usual
  - if updates exist, send a response that contains all required information about them and let a localizer decide what to do: submit new translation anyway or discard it.

Which of these options do you prefer?
How should a localizer be notified about the updates? A dialog with a message and "Keep my translation anyway" and "Cancel my translation" buttons? I clearly see how to implement logic on the client and server sides, but I am not sure about the UI.

Comment 2

[Matjaz Horvat [:mathjazz]]

I was actually thinking WebSockets here. :) But if that turns out to be too big of a task, too complicated or what not, we'll have to fallback to AJAX.

As for notifications, I was thinking something like Google Docs / Etherpad:
1. Simply apply translations in the sidebar and in-place if applicable (also update stats).
2. In the main toolbar, show a list of users viewing the current locale-project-resource combination. Represent usrs with their profile pictures.

Comment 3

[sandra.shklyaeva]

I like the idea about WebSockets too much! 
Well, it's decided. I'll play around with it and let you know when I have something to show.

Comment 4

[:Gijs (he/him)]

FWIW, before websockets the way you used to do this was "long polling" - you'd keep a single ajax request open to the server at all times. The server would just not write a response until it had one, or until about 50-55 seconds had passed (after 1 minute, all kinds of software/firewalls/whatever starts killing TCP things, so you want to make sure you're done before then). If it "timed out", the server would just tell you "no updates!" and otherwise it would be able to write updates to the client listening for them essentially in real time. Once the request returned, the client would just restart the same "poll" request and you'd continue like that. I'm just dropping by via Matjaz' blogpost, so I'm not sure what language is involved here and how you'd do this in that language. :-)

Comment 5

[Osmose [:osmose, :mkelly]]

Peterbe did something similar to what's being proposed here using fanout.io: https://air.mozilla.org/webdev-beer-and-tell-august-2015/#@15m44s

Comment 6

[Matjaz Horvat [:mathjazz]]

See also:
https://www.peterbe.com/plog/using-fanout.io-in-django
https://devcenter.heroku.com/articles/websockets

Comment 7

[BMO Automation]

*This bug has been moved to GitHub.*

*Please check it out on https://github.com/mozilla/pontoon/issues.*