Closed (fixed)
Project:
Translation Management Tool
Version:
8.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
24 Feb 2016 at 10:33 UTC
Updated:
30 Mar 2016 at 00:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
edurenye commentedComment #3
edurenye commentedDone.
Comment #4
berdirAlmost committed this but I actually, this is not strictly true. This is an API. Anyone can call it. You could implement a translator that allows to abort jobs on their side and report that back. You could write a module that aborts jobs that have been unfinished for too long.
Comment #5
miro_dietikerYeah i agree, there are other situations where triggering an abort might make sense.
The problem is, the caller can not really just pass in the message forward with the current API.
So are you saying we can't fix this at all?
Comment #6
berdirYeah, we'd have to pass the message through two messages and all plugins that implement it would have to respect that.
As a not so nice API but easy addition: $job->setDefaultAbortMessage($message, $variables); $job->abortTranslation(). And then aborted() would use that default message if one was set?
Comment #7
miro_dietikerHm that alread hurts when reading. ;-)
I fear if we work on improving messages, we would end up with multiple similar workarounds?
Thought it's a quickfix... Another one. ;-)
I think it's not that important to add a workaround!
Since an abort is final, i could even live with two messages instead:
- The user ordered aborting the Job through the UI.
- The translation job has been aborted.
However, with translator interaction, there is need to have great messages: less garbage and valuable information added instead.
Comment #8
edurenye commentedOk, now if is added using the form it will say:
"The translation job has been aborted by the user."
Otherwise will say:
"The translation job has been aborted."
Comment #9
miro_dietikerNot sure about that direction.
Please read my message #7 and check back with Berdir or me next week.
Comment #10
edurenye commentedReverted all changes, now I just add the message as debug, the user that aborted already now that he did it through the UI, this should be seen just for other users.
I realized that the order of the messages between Job::getMessagesSince() is reversed, should I open a issue for that?
Comment #11
miro_dietikerThe debug severity is too low. That's not a technical debug information. It's user awareness. ;-)
I think the default "status" would be fine because it's a status change.
I also thought about different keys such as "ui" or "info" or "action" but i think we don't have a managed set of those keys and are not using them really yet so we first need a strategy on how we deal with them...
You also change the redirect URL handling.
Does this mean it was broken before? We will need test coverage for that fix.
Also the aborting message should be checked in one location. ;-)
Comment #12
edurenye commentedAdded test for the message.
About the other change, is just a deprecated method replace, works the same way was working before. However it had no test, so I added test for it also.
Comment #15
edurenye commentedRebased.
Comment #16
miro_dietikerThis looks good to me. Committed.