🇩🇪Germany @SteffenR

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.

A similar issue was already created: https://www.drupal.org/project/tmgmt_deepl/issues/3502785 ✨ Translations should be saved using operations to avoid exeeding memory or time execution Active
It’s would be great, if you could check, if the review messages are shown correctly (see screenshot is the issue).

@idebr: If you are still interested in the issue, you may provide more information on what should be taken into account.
By means of the documentation, the task of translating documents is related to "real files", which are uploaded to drupal.
I'm not sure, if this is even possible within tmgmt.

Since there was no further action by @JurriaanRoelofs i'll close the issue/ the related MR.

@walterp: Thx for the reply.
You may test the latest https://www.drupal.org/project/tmgmt_deepl/releases/2.3.0-alpha1 → release and provide feedback, in case anything goes wrong or if the problem is fixed with the use of the official deepl-php library.

I'll close the issue - in case you still have problems, feel free to open a new issue with detailed information on how to reproduce the errors.

@emartos: Great feature request. I've added a few more remaining tasks.
Please assign the ticket to yourself, if you want to start working on the issue.

Thanks in advance,
Steffen

I wanted to use the current MR with version 3.0.
The hook_update_n tablefield_update_8003 is not working with paragraphs.

The following error is thrown:
Base table or view not found: 1146 Table 'db.paragraph_field_data' doesn't exist

I tried to fix by setting the correct table name (should be paragraphs_item_field_data instead of paragraph_field_data), but it still gets stuck on non existing fields for the format (line 100 in the batch).

steffenr → created an issue.

Looks fine for me and should be merged.

I had a look into the code. It looks like the cache handling in method gacGetFeed .
This method should return RunReportResponse, but returns an array in case the results are cached.

@andriic: I've extended an existing content type with a tablefield (using latest stable 3.x release of the module) and tmgmt_deepl 2.2.9.
Unfortunately i cannot reproduce the issue - translations are working fine - also for translatable tablefield fields.
While translating table field content is not shown while reviewing the translation within the job. The only field which is translatable in this case is the caption field.

@andriic: Okay - than your suggestion makes sense.
Can you give me some more information on how to reproduce the issue?
You are writing about "Custom fields" which don't return arrays - can you give some examples?

Thx.

Thanks for the finding. We never run into those issues on our projects.
I would suggest du check beforehand, if $results['translation'] is really and array and is not empty. Otherwise, we would add empty translateData to the job_item, which is not neccessary.

I'll close the ticket, since the module is working as designed. Please use the example code or config to fix the issue.

The problem is related to a field value, which gets translated within the translation workflow and is not related to the module.

You have to define those fields as being non translatable.
tmgmt provides the hook

@divya.pm
You may check the HTML/ content translated within your pages.
The module itself only provides a translator plugin for tmgmt and cannot be held responsible for loading times on your drupal pages ;)..

I'll close the issue for now, since the original scope was explained in full detail..

@davidpetit Thanks for the clarification and your approach to solve it.
I'll close the issue for now. You may open an issue in tmgmt, but it looks like this is more like a drupal core thing and the handling of text formats/ especially the summary field.

@davidpetit
Can you give some more steps to reproduce the issue?

• field configuration
• text to be translated etc.

steffenr → created an issue.

steffenr → created an issue.