🇩🇪Germany @SteffenR

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.

Another reroll of the latest patch for 1.18. I was missing the
use Drupal\paragraphs\ParagraphInterface;
while Copy&Pasting the code.

I just did a quick test run in Drupal 10.2 with existing values and the hook_update_n was working as expected. The length of the field is set to 64.

Thanks @hctom

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

Since we were als using 2904705-128.patch with version 1.16, i did a quick reroll of the patch to get it working with 1.18 also.

Unfortunately you hook_update_n is not working, if you have a database with existing content.

------------------ ----------- --------------- -------------------------------------------------------------------------------
  Module             Update ID   Type            Description
 ------------------ ----------- --------------- -------------------------------------------------------------------------------
  view_mode_switch   10201       hook_update_n   10201 - Increase max length of all view mode switch 'value' property columns.
 ------------------ ----------- --------------- -------------------------------------------------------------------------------

 // Do you wish to run the specified pending updates?: yes.

>  [notice] Update started: view_mode_switch_update_10201
>  [error]  The SQL storage cannot change the schema for an existing field (field_column_layout in paragraph entity) with data.
>  [error]  Update failed: view_mode_switch_update_10201

I'll have a look on it and hope the error is fixed.

The official DeepL-PHP library is being integrated in https://git.drupalcode.org/issue/tmgmt_deepl-3324073/-/tree/3324073-use-...

Can you give it a try please and give feedback?

Looks like the request payload is to big and causes the timeout or your connection is too slow.
Can you give more details on the amount of text you try to translate and give steps to reproduce the issue?

Even after clearing caches the problem still persists.
It's kind of strange, since our custom cookie plugin is working without any problems and the hook_page_attachments is rewriting the code correctly.

@anybody: I do so. I'll have a closer look tomorrow and will run some tests on other machines. Hope we can reproduce the bug on another local environment to find a fix..

We have a similar problem. But in our case this is only happening on live/ staging system.
Our local ddev environment is handling the consent/ rewriting done via cookies_matomo_page_attachments correctly.

On our stage/ prod the cookies_matomo_page_attachments is not working for no reason.
We also implemented a custom cookies service for matomo_tag_manager, which is working/ rewritten correctly using the same logic as cookies_matomo_page_attachments.

We had the similar problem in on of our projects.

The reason was the missing cookiesjsr-preloader.min.js file in the npm asset, since we are fetching all of our external libraries via composer.

This could be fixed by adding the following entry to the repositories section of the composer.json.

"cookiessjr": {
            "type": "package",
            "package": {
                "name": "npm-asset/cookiesjsr",
                "version": "master",
                "type": "drupal-library",
                "dist": {
                    "url": "https://github.com/jfeltkamp/cookiesjsr/archive/refs/heads/master.zip",
                    "type": "zip"
                }
            }
        },

Afterwards you can require (first remove if already installed) the composer package via:

composer require npm-asset/cookiesjsr

Thanks for your contribution. The error went into code while fixing php code quality issues.

In this case, it's sufficient to just check for !== NULL, like i did previously.

Changes were added to latest DEV and the new release.

@Berdir: DO you plan to create a new release for tmgmt, since Drupal 11 was released these days.
Thanks in advance.

@taraskorpach: thx for your contribution.
The changes are merged into the latest 2.2.x-dev release of the module.

@WalterP: No - not out of the box.

You can use the hook_tmgmt_deepl_query_string_alter to alter the query string.
Other hooks and examples can be found in the file tmgmt_deepl.api.php.

Setting translate="no" while handling HTML or XML is the only way to prevent the translation of the content in a tag.
What is your setting for tag handling? This should be set to HTML or XML.

Have you tried other languages with translate="no".

The problem is not related to the module itself, since we only pass all markup to the DeepL API translate endpoint and use the returning values as the translation.

The issue sounds more like a general tmgmt issue and not directly related to tmgmt_deepl, which only provides the translator plugin.
To confirm this, you can try tmgmt_Google as an alternative translator and create an issue in the tmgmt issue queue. Don‘t forget to link the issue as related issue in here.

If the error cannot be reproduced, leave a comment in here and i‘ll have a closer look.

SteffenR → created an issue.

@jurgenhaas Considering the hook_update_n i was also unsure, but maybe we should remove it and add a note to the release notes.
This would be less intrusive and won't destroys customization.

I've updated the MR accordingly and reverted the commit.

SteffenR → created an issue.

SteffenR → created an issue.

Just a quick note.

Due to dependency on tmgmt, we cannot merge this MR, because tmgmt still has missing dependencies/ is not compatible with Drupal 11.

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

SteffenR → created an issue.

Right now there is no better way to just abort the "broken" job items and start again.
Feel free to post a MR dealing/ fixing the issue or make suggestions how this issue should be fixed.
I'm not dealing that much with continous jobs in projects we are using tmgmt_deepl.
The issue is kind of mix between DeepL API limits (free version) and the continous job handling of the tmgmt module.

• hope it's helpfull - the change is available in latest 2.2.2 release

@JurriaanRoelofs
Did you find time testing the Merge Request?
Besides asking for new features, it would be great, if you could help testing issues ;)..

SteffenR → created an issue.

@JurriaanRoelofs I just had a call with deepl on this issue and they don't recommend the chunking of those large text volumes. If we do so, the quality of the translations could get worse, since context is missing.

Therefore i'll set the status to Closed (won't fix), since this limitation is given by the API and will not be changed (for now)...

@JurriaanRoelofs
Some time ago, there was a similar issue concerning the formality level per language. But the suggestion to add the selection right to the checkout process makes more sense.
Please test the MR and give feedback in this issue.

Testing instructions

• run database udpates to get default values for new config setting override_formality
• ensure, that new checkbox Allow override of Formality in checkout is available in configuration form of the DeepL translator
• if Allow override of Formality in checkout is enabled, you'll be able to set the formality level while checkout
• ensure, that the override has an effect on the translations

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

• language Arabic is available in latest 2.2.1 release

SteffenR → changed the visibility of the branch 3431415-add-arabic-ar to active.

SteffenR → changed the visibility of the branch 3431415-add-arabic-ar to hidden.

SteffenR → changed the visibility of the branch 3431415-add-arabic-ar to hidden.

Thanks for the issue. The glossary is buildt upon the possibilities of the API of deepL, that's why cannot create glossaries/ list that are independent from any source or target language.
More information can be found on their documentation: https://www.deepl.com/docs-api/translate-text/translate-text / https://www.deepl.com/docs-api/glossaries

We still need to create one glossary for each language pair to use it, while requesting the translation.

Cloning capabilities

For cloning glossary entities, you can use the entity_clone module.
Since glossary entities are normal content entities, those are supported out-of-the-box by the module.
https://www.drupal.org/project/entity_clone →

Hi JurriaanRoelofs,

Thanks for the issue and the well defined requirements.
I'll take a look at it after my easter holiday.

Usually we had no need handling such large amounts of data/ text within one single field. The internal batch processing of the module is already chunking the input data, but only to split up requests. It doesn't handle the DOM chunking you are looking for right now.

@miki_mike
Sorry for letting you wait for such a long time.
I just tested a similar setup in a D10.2 installation and can reproduce the behaviour. I'll need to spend some time looking a possible causes.
Usually the process of the translator plugin "ends" before adding the translations - this is handled via tmgmt itself.
In the review of translation you can see, that the translated texts are correct, but sth goes wrong while completing the job/ adding the translations to the new node (independent from choosing auto accept or review).

SteffenR → changed the visibility of the branch 3324073-official-php-library to hidden.

SteffenR → changed the visibility of the branch 2.2.x to hidden.

SteffenR → changed the visibility of the branch 2.1.x to hidden.

@recrit thanks for the finding. While developing/ testing the module i was focussed on the "content side" and forgot about the config side, where we might have placeholders.

Therefore the issue is fixed in the latest 2.2.x-dev release.

Since we plan to use the deepl-php library, we will rework all existing tests and add new ones for the glossary functionality.
Therefore this ticket will be closed and marked as being outdated.

Further information: 📌 Use official PHP client library for the DeepL API Active

Thanks for testing the new functionality.
A new 2.2.0 release was just released.

@mrshowerman
Are you sure, that your permissions are configured correctly?

I just did a test on a blank D10 site with just tmgmt and tmgt_deepl installed and got access to the deepl_glossary overview page without the need of the administer permission.

The following permissions are granted to the role content_editor

  - 'access administration pages'
  - 'access content overview'
  - 'access contextual links'
  - 'access deepl_glossary overview'
  - 'access files overview'
  - 'access toolbar'
  - 'access tour'
  - 'administer url aliases'
  - 'create article content'
  - 'create page content'
  - 'create terms in tags'
  - 'create translation jobs'
  - 'create url aliases'
  - 'delete article revisions'
  - 'delete own article content'
  - 'delete own page content'
  - 'delete page revisions'
  - 'edit deepl_glossary glossary entries'
  - 'edit own article content'
  - 'edit own comments'
  - 'edit own page content'
  - 'edit terms in tags'
  - 'revert all revisions'
  - 'view all revisions'
  - 'view own unpublished content'
  - 'view the administration theme'

I'll have a further look.
I my testing it was sufficient to just set access deepl_glossary overview and edit deepl_glossary glossary entries..

@mrshowerman Thx for the findings. I've changed the code according to your suggestions.
All occurences of deepL where changed to DeepL (like in their API documentation) and the description text was updated.
I also run a phpstan/ phpcs test against the tmgmt_deepl_glossary submodule and added some fixes.

The time was sponsored by my lovely daughter, who is currently at the swimming competition. (Dad taxi 🚕🚕🚕)