🇩🇪Germany @SteffenR

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

steffenr → created an issue.

• fixed and released in version 2.2.9

@anpolimus
Can you show me the configuration of your translator. While looking at the source code in the screenshot, the whole translation seems to be messed up.

The configuration should look as following:

We are using the module also with Full-HTML on larger sites and never had those issues.

To reproduce i need the following things:

• configuration of the deepL translator
• HTML source/ text, which should be translated

steffenr → created an issue.

@ayalon: Thanks for further testing. I also did some test in more complex setups on our site.

I'll prepare a new release for the module.

Hi Julian,

Thanks for the issue.
Since the module is already passing the parameters via POST only the auth_key needs to be changed and authorization needs to be done via the Authorization header.

You can help reviewing the folliwing issues and test the branch 2.3.x-dev on a more complex site.

Needs Review Tickets:

• ✨ Glossary entries alternative UI Active
• ✨ Allow passing translation context in translation checkout Active

Afterwards i plan to release a 2.3.0-alpha version.

steffenr → created an issue.

@duaelfr: Feel free to test the new feature with the latest 2.3.x dev release.
But keep in mind, that you need to install the module via composer to get all new dependencies.

steffenr → created an issue.

Yep - that's not a problem.

I just had the plan to build up a fully tested release. But as always it's about time ;)

@idebr
Actually i wanted to complete the test coverage of the code.
But at the moment I don't have the time to complete this, as writing the tests takes up more time.

From my point of view, it's possible to create a 2.3.x development release, that you can use as a starting point for your work on ✨ Support translation of documents Active .
What do you think?

@harishwar r
Do you have a glossary for the language - e.g. english -> spanish?
Have you re-synced the glossaries on prod?
I already mentioned, that this could be related to glossaries, you are using on stage and production. In case of changing entries on stage and saving those, you get inconsistencies and previously used glossary_ids on prod won't work.

For further investigation, i need more steps to reproduce the issue. Since it's working on you staging system, the module is working fine.

But for your internal investigastion/ debugging i would suggest the following steps.

• get a latest database dump from production, where the error exists
• try to reproduce the error on your local environment
• use a debugger to check the query send to the deepL API
  • use postman or equal tools to check for existence of glossaries by running API calls against the glossary endpoint
  • use postman and rebuild the original query and run the API calls against the translate endpoint

Further info on API usage, can be found here: https://developers.deepl.com/docs