Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Aborting a translation currently does not lead to any notification of Gengo.
Proposed resolution
Implement.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#9 | implement-2543308-9.patch | 4.15 KB | Bambell |
| |||
#7 | gengo-abort-warning.png | 18.03 KB | Bambell |
#5 | gengo-3-3.png | 9.57 KB | Bambell |
#5 | gengo-2-3.png | 9.65 KB | Bambell |
Comments
Comment #1
Berdirhttp://developers.gengo.com/v2/api_methods/job/#job-delete
Comment #2
miro_dietikerThis applies both to aboring on Drupal side and aborting on gengo side.
Either an immediate update should happen, or the state should be pulled on button press.
Both abort states should be in sync to avoid malfunction.
Comment #3
Bambell CreditAttribution: Bambell at MD Systems GmbH commentedHere we go. Adds a bit of overhead, but personally I would also query again the API for the jobs' status, to double check, and would clearly return the ID of the jobs that were aborted to reassure the user.
Comment #4
miro_dietikerA quick review. No reason to double check. APIs do what they describe and you get a success/error message.
This is wrong. It's added to every abort form and also applies if it's not a Gengo provider.
There is the JobInterface::abortTranslation() and you don't need to attach through a form at all.
For an example see: tmgmt_oht/src/Plugin/tmgmt/Translator/OhtTranslator.php
That's not really an error. Also we don't use drupal_set_message() in tmgmt. We attach messages to the job.
The user can abort a job always. But we can not tell the user if it leads to a cancellation at the provider. Also many providers will not refund at all if you cancel.
Thus, we simply try to cancel the jobs and create a SINGLE message on the job like X of Y messages have been aborted at Gengo.
Comment #5
Bambell CreditAttribution: Bambell at MD Systems GmbH commentedI have modified the patch in order to implement
JobInterface::abortTranslation()
, instead of hooking into a form, and no longer use usedrupal_set_message()
, but rather set messages to job items. With the current implementation, jobs can always be aborted on TMGMT's side. A single message is added to the job item ("X job out of Y has been aborted at Gengo" or "X jobs out of Y have been aborted at Gengo"). The message is no longer an error. Would it be appropriate to set it as a warning in case job(s) couldn't be aborted at Gengo?Comment #6
miro_dietikerYeah looks good now. And yeah, if not all can be stopped, warning would be the best level.
I think you should add to the warning "Gengo does not allow aborting jobs that are already in translation."
Comment #7
Bambell CreditAttribution: Bambell at MD Systems GmbH commentedI re-rolled the patch, changed the wording in case job(s) couldn't be canceled and changed this message level to a warning.
We can also abort the order at Gengo. If there's a job in the order that can't be canceled, I believe that none of the order's jobs is canceled. We could then deny abortion on TMGMT's side.
Comment #8
miro_dietikerI like the presentation almost wanted to commit.
I feel blind.
I see only 2 real cases. Why 4?
Comment #9
Bambell CreditAttribution: Bambell at MD Systems GmbH commentedAs discussed, I changed the wording from "X job/jobs out of Y has/have been aborted at Gengo" to "Aborted X out of Y jobs at Gengo". I tried considering the singular form of "jobs" with
formatPlural()
, but strangely I couldn't get it to work :$total_jobs = \Drupal::translation()->formatPlural($count_remotes, '1 job', '@count jobs');
With that wording, though, it's so very unlikely that a node will only have a single field that we can probably leave the singular form ("job") out?
Comment #10
Bambell CreditAttribution: Bambell at MD Systems GmbH commentedComment #11
miro_dietikerWorks for me now. :-)