🇩🇪Germany @SteffenR

Sorry, but I don't see the need for a "Remove/ Reset API key" button.
This would make the tmgmt translator plugin config useless and may cause errors, while trying to use the translator within the standard tmgmt workflows.
I would suggest to configure a translator within tmgmt for "one time translation use" and delete it afterwards.

Interesting.
I just had a look at both version 2.2.x and 2.3.x (which uses the key module for storage of keys) and was not able to save the translator without providing an API key.

Since you are talking about the "Connect" button, it looks like you are using version 2.2.x of the module. In case of not providing an API key within the field, the translator is "kind of useless" within the Drupal and could lead to potential errors, while trying to use it.

Based on the experience of our project, it makes sense to always configure the API key (of the customer) and - in case of testing - provide a config override, which uses your companies or any other key.

@dualfr: Could you recheck the MR and fix the failing phpstan tests please ?

With the latest changes, the version 2.3.x is now supporting multiple dicitionaries within one glossary.
This allows free accounts to work with a single glossary (which is the limit) but having several dictionaries for the languages within the drupal installation.

I also get a similar message on the edit provider page, in case of having file translation active.

( ! ) Deprecated: Drupal\tmgmt\Data::createFileTranslation(): Implicitly marking parameter $destination as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/web/modules/contrib/tmgmt/src/Data.php on line 313

Thx for the fix and reviewing ;)

@phily The issue was already fixed some month ago.
I added the related issue to this one.

@anneke_vde thx for testing. Looks fine and will be merged into 2.3.x .

steffenr → created an issue.

steffenr → created an issue.

I've build up a simple setup with a basic content type containing a translatable file field.
After attaching a PDF file and hitting the translation workflow the PDF is being translated without issues.
The translated file gets attached to the translated node and results look fine. DeepL is doing a good job while translating and keeps the structure/ formatting of the document.
I've attached the PDF as an example in here.

The MR will be merged into 2.3.x.

Thanks for your support and cleaning up legacy code.

🚀 Thanks - looks fine for me and will be merged in 2.3.x 🚀

It would be nice, if you could add testing instructions on how to use the document translation.
I think i'll find some time next week for further testing - right now i'm heavily involved in projects at work.

@just_like_good_vibes
I run into another issue, with displaying sub menu items of a given parent.

If you use the default UI Patterns menu component (in my case ui_suite_daisyui), you would get all the submenu items and not only the ones related to the parent.

This can be fixed in MenuSource->getMenuItems by using:

$parameters = $this->menuLinkTree->getCurrentRouteMenuTreeParameters($this->menuId);
instead of
$parameters = new MenuTreeParameters();

That's a great addition.
Some time ago i had a look at this behaviour, but was not looking further, since it's just one of those "nice-to-have" things ;).
But the issue in tmgmt looks promising - hope they get it merged soon.

steffenr → made their first commit to this issue’s fork.

Thx for your contribution and the findings.
Looks fine for me and will be merged.

Thx for your contribution and the findings.

Thx - looks fine for me.

@pfrenssen Thanks for opening the MR.
I just had a quick look and could reproduce the error. With the change applied, it works fine again.

I'll prepare a new alpa release.

steffenr → made their first commit to this issue’s fork.

@berliner @renrhaf
You can use the latest dev version of the module, which is compatible with D11 and can be easily installed via composer.
Just use the command:
composer require 'drupal/multiple_registration:3.x-dev@dev'

Maybe we should add something like a language mapping configuration for the remote languages.
The tmgmt module is doing something like this within its configuration.

Hi @anybody.
Can you give me some more information on how to reproduce the issue within a simple setup?
Or do i need to "spin up" a commerce installation, were you originally found the issue.

Hi @anybody - thx for posting the issue.

Looks like the issue is related to the broken return value, as you already mentioned.
We never run into those issues on any of the sites, we are using the module (but we never tried it with commerce entities/ just "normal content").

Usually the translations are added to the Drupal entities within the batchFinished callback.

Another approach would be saving the translations in the "processing step" - there is already an issue concering the process: https://www.drupal.org/project/tmgmt_deepl/issues/3502785 ✨ Translations should be saved using operations to avoid exeeding memory or time execution Active
But this "kind of breaks" the display of completion messages. Maybe you have another idea, how the messages can be fetched and displayed correctly ✨ Translations should be saved using operations to avoid exeeding memory or time execution Active .

johannes stahl → credited steffenr → .

@hhvardan @andy inman Thx for your feedback.
Renaming the action is not "a big deal" and as you mentioned, it sounds like it makes more sense.

I've updated the MR accordingly. Maybe you can have an idea, how to get the configured third party setting within the hook_paragraphs_widget_actions_alter.
I did some debugging, but it looks like there is no easy way (besides loading the whole widget configuration) to get the widget config/ third party settings in here.

steffenr → created an issue.

@sascha_meissner
👍 Thanks for fixing the issue. 👍

@blyme: We had a similar request from one of our customers.
MR is ready for review ✨ Allow pasting copied paragraph with "Paragraph actions"/ improve validation Active .

steffenr → created an issue.

Without knowing your configuration/ mapped languages it is hard to help in this case.
Since it is working with other languages (other ckeditor fields), the error seems to be somewhere else.

steffenr → created an issue.

steffenr → created an issue.

@divya.pm As is already wrote in my last comment, the issue is not related to the tmgmt_deepl module. Please check your field settings and multilingual related functionality.

Sorry, but I cannot give support for that issue - therefore it will be closed again.

@jossensei: good point and thanks for the patch. I've added the missing check to the Merge Request.

steffenr → changed the visibility of the branch 3522010-migrate-v2-to-v3-glossary to hidden.

steffenr → changed the visibility of the branch 3178100-paragraph-validation to hidden.

steffenr → changed the visibility of the branch 3178100-paragraphs-cant-get to hidden.

steffenr → changed the visibility of the branch 3178100-content-moderation-support to hidden.

I just did a run with drush updb -vvv to get further information on the error.

Looks like it is related to the apitoolsmodule.

steffenr → created an issue.

@bit-checker: The issue was fixed in 🐛 DeepL glossary missing Arabic as source and target language Active and is available in the latest 2.2.x branch.

I just had a look at related issues, which would be affected by the Merge Request.
I have to make some more changes to the selection of languages, since custom langcodes, which are mapped in the translator configuration won't show up.

@sachit.thapa: The tests for phpstan (next minor) won't be fixed for the 2.2.x release.
Those are handled in 2.3.x - were all pipelines are green.

It would be great, if you could test the Merge Request with version 2.2.x on you projects and provide feedback. Afterward i'll integrate the feature into 2.3.x.

steffenr → created an issue.

Sorry, but this issue is not related to the tmgmt_deepl module.

Please use the tmgmt issue queue → for that purpose.

The language Arabic is not supported by the API for now.
Available languages are listed here: https://developers.deepl.com/docs/api-reference/glossaries/openapi-spec-...

Once the language is available via the API, i'll update the tmgmt_deepl_glossary submodule.

I've added the related issue, were this behaviour was changed. More info can be found there.

Can you create a Merge Request please, that checks for EN-GB/ EN-US and rewrites the mapping?

Thanks.

steffenr → created an issue.

The issue is not related to the module. It’s a more general issue with translatable content and related configuration.
Please check to /admin/config/regional/content-language what’s configured for the title of the entity.

Therefore I will close this issue.

@igor thx for the Patch.
Have you checked the described behaviour within the issue concerning the output of messages?
Since you moved the saving as a batch operation, this would end up it multiple separate messages instead of displaying “all in one” like shown in the screenshot.