Inform user about submission status [#568028]

Currently we save errors into the watchdog when the remote submission did not work, but do not inform the user. It can still happen that someone generally has the permission on the server to use remote submission, but is not a member of the groups it is being submitted to, which overrides the general permissions for good reasons. So we should inform users when a remote submission error happens. There is also that case of course that the server is not up, etc. Basically, the l10n_client_submit_translation() code should somehow communicate errors back to the JS UI.

Comment	File	Size	Author
#9	user-feedback-d6.patch	7.95 KB	Gábor Hojtsy
#9
#8	user-feedback.patch	7.89 KB	Gábor Hojtsy
#8
#7	RemoteOpportunity.jpg	30.93 KB	Gábor Hojtsy
#7	RemoteError.jpg	32.36 KB	Gábor Hojtsy
#7	Saved.jpg	24.59 KB	Gábor Hojtsy
#7	user-feedback.patch	7.83 KB	Gábor Hojtsy
#7

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

j0nathan CreditAttribution: j0nathan commented 30 May 2010 at 23:14

Hi,
Would it be a good idea to inform the users also when the submission worked correctly so they know the translation got shared with the community?

Comment #2

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 31 May 2010 at 08:08

Yes, it would be good to find a good place in the UI to provide this feedback on success/error.

Comment #3

Jose Reyero CreditAttribution: Jose Reyero commented 15 September 2010 at 13:32

I think this should be part of a more general issue about keeping track of translations, who submitted them and whether remote submission was ok, on some local table.

It would be nice too having the option to re-submit translations, and maybe being able to run batched submissions.

Also I don't think we are even informing users whether submissions have been successfully saved locally, so this calls for a whole submission status / error handling ui.

A good starting point IMHO would be:

- Add some last submission status indicator on the js UI, so it informs but it doesn't interrupt normial workflow (a pop up would be too intrusive as it may interrupt you every time submission had some trouble, which may be because the server is down for some period of time, which would render the UI unusable)

- Keeping records on a separate table of who submitted what when, which will allow us to check the status of the whole thing and also to resubmit when there was a temporary submission problem.

Comment #4

smoothify CreditAttribution: smoothify commented 7 October 2010 at 23:03

+1 for Jose's suggestions

I've just been trying out l10n_client for the first time in local mode and I did feel very much in the dark about what happens after saving.

I'm thinking about providing the tool to a translator, but i'd like to keep an eye on what they have translated and make sure they don't break any of the tokens when editing the text around the site.

Comment #5

andypost

he/him

Russian

CreditAttribution: andypost commented 13 October 2010 at 12:35

Comment #6

podarok

🇺🇦 he/him/his

Ukrainian

Ukraine

CreditAttribution: podarok commented 8 December 2010 at 11:43

possibly better way is to make job_queue for submitting strings via cron

Comment #7

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 8 December 2010 at 13:58

Title:	Inform user on submission if string was not saved remotely	» Inform user about submission status
Status:	Active	» Fixed

File	Size
user-feedback.patch	7.83 KB

Saved.jpg	24.59 KB
RemoteError.jpg	32.36 KB
RemoteOpportunity.jpg	30.93 KB

Ok, here is a fairly complete solution for the problem. I decided to reuse the "source" display field. This is overwritten once you select your next string to translate, but otherwise displays the message permanently, so you can act on it, if it is a warning or error.

There are basically two messages: one for local operation the other for remote operation. The remote message is only ever displayed if the site is configured for remote submission, otherwise the user is not bugged. But if the site is configured and the user is not, the message tells the user he misses out on an easy way to contribute:

Remote errors are displayed similarly, such as if you did not set your API key properly:

Finally, if all goes well both locally and remotely, it is all green and nice and it tells you you put in your bit to the community.

Local error messages are similar but obviously affect the first item.

I imagine we will keep iterating on the display, colors and text of these messages, but I think this is a huuuuge step forward, so committing this ASAP (and will work on backport as well).

Comment #8

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 8 December 2010 at 14:02

File	Size
user-feedback.patch	7.89 KB

Added the word "locally" to the local feedback when the remote submission is not aborted due to local error, so it is cleaner that local and remote status can be different (was not clear from the screenshot above). Also, only send 'default' textgroup strings to the remote server to avoid extra communication that is guaranteed to be fruitless.