Closed (duplicate)
Project:
Localization client
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
18 Jan 2010 at 11:23 UTC
Updated:
4 Aug 2010 at 11:15 UTC
We ran into issues where some matches didn't occur on server and l10n_client submitted translations got lost.
Currently we're mot using AJAX success: feedback to provide information to the user about the current state.
This is very dangerous as we should report what really happened after save and also consider it for local action.
What do you think how should the response drupal_json data be formed to talk to the client?
(we might transfer update count, response message, ...)
Comments
Comment #1
gábor hojtsyWell, we have this remote call in l10n_client_submit_translation(), which stores any errors in the log (via watchdog()) but does not return the error itself to the caller and especially not to the original browser client. To display a meaningful error message, @hass already suggested in a follow up comment to #323914: New 2.0 remote API with seamless user experience and services architecture to include a list of these errors strings in l10n_client and l10n_server to make them translatable and displayable on the UI.
So we'd need to (a) include a list of these in l10n_client (b) actually return a message to the client and at least display that on error in some way. I'm closing #323914: New 2.0 remote API with seamless user experience and services architecture for now, given it was only open for this and was fixed in itself.
Comment #2
gábor hojtsyRetitled to be more specific.
Comment #3
hass commented+
Comment #4
miro_dietikerGabor, while i fully agree we should also provide feedback to user about remote submittions (you're talking about server) i was primarily talking about local (direct client) action feedback.
If you look at _locale_import_one_string_db, there could happen pretty anything.
We should only confirm saves with current OK-green in the client if they get saved. and we should only remove the string from the textarea if it got saved successfully.
I'd add a status line for text response display from server, add colourful states, add ajax processing icon (like views does), and possibly alert if something really breaks (0 updates during l10n_client_save_string).
Sure right these mechanisms are also the best base for further l10n_server feedback, but it all starts in the client, its "local processes", its usability, and in l10n_client_save_string local action initially.
Comment #5
gábor hojtsy@miro_dietiker: I think both of us are talking about l10n_client, what I'm saying is that the l10n_server feedback should be displayed with the same mechanisms. Removed "remote" from the title to make this more correct.
Comment #6
gábor hojtsyDuplicate of #568028: Inform user about submission status.