Create job for multiple target languages

I need the same functionality. I send my content off for 28+ languages. Ideally, I would be able to create a single job that applies to all enabled languages. The translation service I use, for which I've written a custom translator plugin, accepts a JSON file and begins to translate the content into all languages requested.

I think a views bulk operation "Request translation" would be a good solution here.
It can be used at /admin/tmgmt/jobs to submit multiple jobs.

What do you think?

Again, we decided for an own source UI, based on core components. VBO is not ready yet.

Aren't bulk actions in Drupal 8 core? See Drupal\system\Plugin\views\field\BulkForm.
There are already VBO actions available. E.g. check /admin/content

Miro, could you please tell about the challenges with the VBO module, if that was the issue.

Hello-

Bumping this. What is the desired architecture for submitting multiple jobs at once?

The inability to submit multiple languages at once is a huge problem for dealing with some translation vendors, e.g. Smartling currently charges per managed word. Under D7 TMGMT/Smartling, it was possible to do this, that is submit say an English source document to 30 languages at once.

Under the current architecture, doing the same requires 30 individual submissions to a translation service. From a UX perspective alone this is very tedious, but it also incurs added costs with some service providers. E.g., with Smartling, if the jobs are submitted at-once like they were with D7 (and therefore managed by Smartling together), a 400 word document is 400 managed words, regardless of the number of target languages. With D8 TMGMT, this becomes 30 * 400 words, or 12000. The costs are a bit different.

Correction here: submitting the files individually does *not* incur different costs with Smartling. That was a misunderstanding on my company's side.

https://www.drupal.org/project/tmgmt_extension_suit supplies a way to create jobs in bulk, so the Drupal side is roughly taken care of there.

This makes TMGMT D8 nonviable for any sufficiently large site. It needs to be resolved.

I do still think this makes TMGMT D8 much harder to work with, but it sounds like we have workarounds. Still, would be very happy to help make this better, if there's an architectural path forward.

I'm very happy to throw development effort at this to make it work. I just need to understand what the desired architecture is. Reading this issue and also https://www.drupal.org/node/2686071, it looks like there needs to be other contributors besides the maintainers (who already maintain huge amounts of contrib code)>

@miro_dietiker, what's your desired architecture/direction for submitting multiple languages? Very happy to help.

Hello guys,

Any news about this feature?

-> Can the select language inside a job can be a multi-select? Is it tricky?

Thank you.

In short:
1. Refactoring Jobs as a Drupal entity to have multiple target locales - is a HUGE refactoring, I doubt anyone will do.
2. It is possible to create UI where you could select multiple locales, that would create multiple Jobs in different selected locales. It is one of the features that was implemented in https://www.drupal.org/project/tmgmt_extension_suit so I would recommend to take a look at this module

P.S. I'm one of the authors for that module.

I think, that another really good thing about Cart right now is that it allows to select source language other than site's default language. And so potentially you could translate English into Spanish and then Spanish into French. Though this might result in somewhat messy hierarchies, but some of our clients wanted that.

Another thought is that currently, the Cart forces you to submit a form for each language you choose. So if you select 20 languages, you would need to submit 20 forms, which might be somewhat time-consuming...

The main problem is that this doesn't work with many translators as they have settings, quotes and other information that you need to provide.

If you only have a single provider that doesn't have any settings (e.g. google machine translation works well for this), then we automatically, by default, use the auto-checkout mode.

I just tested on a test site with 4 languages and only google translator, auto-checkout enabled. Added 4 nodes to cart and translated into 3 languages. Without a single confirmation, I got a whole bunch of confirmation messages that the job item is now ready for review. And if I'd also enable auto-accept, they'd be translated automatically.

One possible, relatively easy feature that might not work in all cases is adding a checkbox to the first job of a multi-job checkout process:

"[ ] Use same settings for N additonal jobs"

That would copy over the selected translator, settings and so and attempt to automatically submit those jobs as well. and if validation fails, e.g. due to an unsupported language combination, then the user will be asked to continue manually.

>The main problem is that this doesn't work with many translators as they have settings, quotes and other information that you need to provide.

Could you please advise what exactly doesn't work?

Simple example, some translation service providers have category/quality settings, that depend on the translation language (e.g. EN => FR) not all categories or qualities are available for all combinations. Then you select category X for EN => FR, but it won't be a valid category for EN => DE and the submission will fail for that job.

Thanks, now I see it, I think that's a valid use-case. On the other hand, you might agree that if you have 20-50 locales and don't have locale-specific settings - it might be time-consuming to submit each form. So perhaps it's a good thing both approaches exist.

P.S. We mostly tested TMGMT Extension Suite with our own provider, but tried hard and it seems that we managed to keep Extension Suite code vendor-agnostic. So issues/contributions/patches are welcome.
P.P.S. Perhaps we should stop flooding this issue with discussion of another module, and continue in a separate thread, if you'd like.

It would indeed save time. Another use case is where pricing is based on each job. You'd want to have one job with different languages.

I could imagine the checkout form 'growing' with extra parameters when a language is added that requires specific settings.

Just a small update on this old issue.

> "[ ] Use same settings for N additonal jobs"

This does exist since 2018 already: #2913887: Allow to create jobs for multiple target languages from the source overview

It's however still N separate jobs and translation provider API's are isolated to a single job, they have no idea how many are to come, how they are grouped and so on.

A relatively easy addition that I recently discussed with someone would be a new interface "MultipleCheckoutInterface" that has requestTranslationMultiple(array $jobs), so if the selected provider supports that, instead of calling requestTranslation() in a loop on all jobs, we'd pass all jobs to it at once, and then it would be able to put them in a single translation project on its side or whatever.