This is a far fetched feature request and I firstly want to discuss this with you here. Surely I will help with implementing this.

What we need is the possibility to add quality assurance services, for the review step.
So the workflow would be creating a job -> translate the job by a translator -> review it by a review module -> finished.
What I imagine is something like translator/source infrastructure for the review step.
Every job have besides the translator and source plugin a review plugin.
The current implementation from tmgmt_ui then would be the equivalent to the local built in translator.
But when a user has some QA system, he can tie this together with the tmgmt module.
If a job is set to review, then a function is called in the review class, which starts the review process. For the local review, this maybe would only add a message, where the user can find the review form. For other services this maybe would send the data to the QA service or something similar.

What do you think about it?

Comments

schnitzel’s picture

schnitzel commented
Component: Source: Node » Core

sounds interesting. We never thought about this specific case because we thougth that we are fixxing all the cases with the internal Review Step. And for this we already talked with people which do reviews every day.

But maybe you could give us some more details about your usecase? What would happen in this QA service?

From a technical point of view you could already do this with just an external module which takes all the Jobs which are in Review and does something with them. With menu_alter you could also prevent users from accessing the core review form (I know hacky but if you really need it right now)

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Yeah, not sure what kind of QA processes you're talking about, can you give an example?

As Schnitzel mentioned, you should be able to invoke something in a custom module when a job item has it's status changed to needs review. You could do that with a rule or a hook implementation in a custom module. And once your process did run through, you should be able to accept the translation through the API (or Rules, not sure if we have an action for that yet, probably not).

The improved permission system that I've started to work on includes an accept translation permission. Don't give your users that permission and they shouldn't be able to manually accept something.

kfritsche’s picture

kfritsche
Primary language German
Location 🇩🇪🇪🇺
commented

Sorry for my late answers every time, but i do not forget about this ;)

The QA will be an external service like the translators. Currently I don't have any more specifics about this, as this is work in progress.

The firm where I'm employed is part of the W3C working group MultilingualWeb-LT and we are implementing this in Drupal and trying to use TMGMT as much as possible. (btw: great work so far! :) )
As this is all work in progress, this is a proposals, where I would like to hear from the dev-team, what should be in an external module and what maybe can get inside TMGMT.
Currently it seems so that the CMS calls all the services in the translations process and therefor an colleague had an even more complex idea to make the workflow more adjustable.
His idea was to have a list of services, where you can pick from and order this. A service could be anything from a translator to a review service. In the translation process each service is called in the order given. An easy example would "Microsoft Translator (machine translation) -> Local Review" and more complex one "enriching data -> machine translation -> LSP review -> QA" (there could be even more or less). Where enriching data is a external service, which adds meta data for the translator to the text and LSP review and QA will be properly an external service too. If you only add a translator (which would be required ;) ), this would be the same as the option "Allow translators to automatically accept translations". This would be an much more modular and more complicated way, than it is right now. Instead of selecting a Translator for a job you would choose a workflow for the job - which the standard name should be the one of the translator added to the workflow. So you can have different workflows for different translators, like for the Microsoft Translator add an review, for the mygengo translator auto accepting the translation and for a translator which supports the new meta data, add a enriching service before sending the data and so on.
I know that I can do this the hacky way with hook_update or maybe even write a meta-translator module, which does this. But as mentioned above I don't need this right away as it is for new standard that is work in progress and I surely will implement this. So the question would be, which of these parts could get inside of TMGMT and for which one I definitely have to do another maybe hacky way?

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Hm. I think the checkout job user interface shouldn't get more complicated. Also, I guess these configurations are global, you don't want to set this up again for every new job, right?

So it makes sense to have all that as part of a single translator (not necessarly plugin), where you can set up a pre-defined workflow that you just need to select on the job checkout. There we have two options I think:

a) Build this right into the core and e.g. allow that translators can have a queue of translator plugins which separate configuration for each.
b) Provide this as a new Translator plugin, which could be called e.g. "Workflow" that allows to do this queue stuff as part of it's "translator" settings. TMGMT will see it as a single translator.

For the moment, I'd suggest to try option b). That allows to try and implement something like this as a separate project, play around with the user interface and how it could work. We can still look into merging it and making it part of the main module or maybe parts of it. The problem with that could be that, while it might work fine for the outgoing process, the ingoing stuff could be tricky because translators just add their translations through $job->saveTranslations() and the workflow translator might not have a chance to intercept. However, we might be able to solve this with a few added hooks or so.

schnitzel’s picture

schnitzel commented

I agree with Berdir, the "Meta Translator" would also be the way to go right now. If it really works cool and could add improvement for existing TMGMT Users then we can think about adding it to the TMGMT Core.
But right now we really should focus on not adding more features to TMGMT and finish a first stable version :)

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented

Really interesting topic. Great opportunity to try out new ideas.
Note that we're currently also working on the internal review workflows.
One related issue is #1570712: Tracking rejected items