🇩🇪Germany @SteffenR

@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.

@igor mashevskyi: Thanks for you patch. I've created an MR and merged the changed into the latest 2.2.x release.

@amateescu: Ah i see.
Thx for integrating the changes directly into the module. Just had a closer look at the changes you made ;)..

@beltofte: Thanks for helping out.
I planned to release an alpha release mid/ end of february. Right now i'm also busy doing other projects.

steffenr → created an issue.

@amateescu: thx for you comment. I hadn't thought of this possibility at the time. That makes sense.

Unfortunately it is not possible to fix the CI problem without putting views_bulk_operations in the root composer.json of the module.
Within a submodule the dependency is not recognized by the default workflow.

That's why i will close the issue and build a separate project containing the functionality.

@beltofte: I just checked the MR and its working fine.
Using the remote language mappings really makes sense in getMatchingGlossaries. I just ask myself "why have i solved it the other way?" ;)

Thanks for your contribution!

The glossary entities use the available languages provided by the API: https://developers.deepl.com/docs/api-reference/glossaries

In case of having custom language codes on your site, you should also use ISO 639-1 notation.
The correct language code for San Marino - Italian would be it-SM (https://localizely.com/locale-code/it-SM/) and not SM-IT, since the San Marino italian is a subset of the original italian language.

The glossary matching functionality will always take the first two letters based on ISO 639-1 and will use this for its matching logic.

steffenr → created an issue. See original summary → .

Good point and thanks for the finding. I just did a test with lots of content and multiple languages and its working fine for me.

But it still needs work, since we loose the display of the translation messages, which are shown after the batch has run.
If translation job need review afterwards, the messages would look as following:

It would be great, if you could update your patch or even create a merge request with the changes.

Thanks so far.

I’ll close the ticket, since it was a configuration issue.
The default should be kept to be „off“ and users can enable the tag_handling as desired.

steffenr → created an issue.

Since you are translating content, which includes HTML tags, you must set tag_handling to HTML.
Otherwise you run into problems, like you are showing in the issue.

More information on tag_handling can also be found in the DeepL API documentation: https://developers.deepl.com/docs/xml-and-html-handling/html