🇩🇪Germany @SteffenR

@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

steffenr → created an issue.

When I create the EN page, it automatically translates to ES without requiring me to select the "Request Translation" button. Is there any configuration required?

This is not an tmgmt_deepl related issues - sounds like you have configured a continous translation job within your tmgmt configuration.

No I have not resynced, Should I click the "Sync DeepL Glossaries" button on admin/tmgmt/deepl_glossaries ?

In cases of using a glossary on multiple instances (e.g. staging, production) we had the issue, that non existing glossaries led to 404 errors while translating. But this can be fixed by simply syncing the glossaries.

@divya.pm
Have you tried using the latest version of the module ?
Do you use the tmgmt_deepl_glossary module and have you resynced glossaries?

I'm aware of the translation workflow, since i wrote the module ;) ..

Can you give some more information on the language mappings you did and a screenshot of you tmgmt configuration?

steffenr → created an issue.

I'll have a look on the issue. Looks like the configuration of the unit tests needs to be updated.

Additional info: https://www.deepl.com/en/blog/deepl-translator-now-supports-traditional-...

@cyrille.miskiewicz: Feel free to add a MR adding the new language.

I've added a new MR fixing the issues, since the MR provided by the bot was missing some additions made to the module.

steffenr → changed the visibility of the branch 3451351-automated-drupal-11 to hidden.

steffenr → changed the visibility of the branch project-update-bot-only to hidden.

@rgpublic: You are right but ;)
In our case, we did not switch to paragraphs_asymmetric_translation_widgets module, since few sites only get security updates in terms of module updates. In this case, it made more sense, to fix the existing patch for the latest paragraphs version.
For our recent projects we switched to paragraphs_asymmetric_translation_widgets and use the "minimal" version of the patch proposed in this issue..

steffenr → created an issue.

I've created a new MR, because updating the Fork/ re-applying the changes messed up the old one...

steffenr → changed the visibility of the branch 2.x to hidden.

steffenr → changed the visibility of the branch 3224400-missing-resizeobserver-api to hidden.

steffenr → changed the visibility of the branch 2.x to active.

steffenr → changed the visibility of the branch 2.x to hidden.

steffenr → changed the visibility of the branch 3224400-2.x-missing-resizeobserver-api to hidden.

steffenr → changed the visibility of the branch 3224400-8.x-1.x-missing-resizeobserver-api to hidden.

steffenr → changed the visibility of the branch 3224400-8.x-1.x-missing-resizeobserver-api_rb1 to hidden.