🇩🇪Germany @SteffenR

@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 🚕🚕🚕)

@mrshowerman
The changes can be tested in the latest 2.2.x-dev release of the module.

I've also added a new permission access deepl_glossary overview to simplify access handling.
Two hook_update_n take care of updating existing user roles with the new permissions.
Feel free to test and give feedback.

Yep. Just leave a comment in here. I'll take care of those issues. Thx.

@mrshowerman: Further work on this topic should be covered within a new issue. May you check the Proposed resolution there and comment in case i'm missing sth..
Thx.

SteffenR → created an issue.

@DuaelFr: I justed wanted to ask, if everything went fine, while implementing the feature?

I've updated the patch and added the missing D10 related entries to the .info files.

SteffenR → created an issue.

@miki_mike & @desch:
Can you give more information on your configuration?
Have you tried another translation service?
Please read my comment above and give steps to reproduce.

Thx

SteffenR → created an issue.

The patch still had problems while translating entities, because the route object did not contain the _entity_form key.
I added an additional check for filled $form_arg and a logic to get the entity_type_id from the route object.

I'll mark the issue as being fixed, since the new version 10.0.0-beta1 is compatible to D10.

Can you share your configuration of the paragraphs field and the widget settings?

Looks like a confguration issue, since the review process/ validation is not part of the tmgmt_deepl itself. The review/ validation is handled via the tmgmt module. tmgmt_deepl "only" provides a plugin to use the possibilities of deepL.

We are using the same combination on one of our clients projects without any problem.

Updated patch and add changes to info.yml to fix compatibility issues.

The issue can be solved with the patch provided in https://www.drupal.org/project/drupal/issues/3332416 🐛 CKEditor 5 toolbar items of multi-value field (typically Paragraphs) overflowing on narrow viewports and overlapping with node form's sidebar on wide viewports Active .

I think we can mark the ticket as Closed (duplicate).

And another reroll, because the method entityIsPublishable was not working correctly, because the name of the module was passed to getDefinition instead of the bundle name.

@AndreRB: It would be great, if you could update the MR with the latest patch. 💚

Finally.. ;) Sorry for confusion in the last comment.

Updated patch, cause i missed a duplicate line..

I've updated the patch to work with latest 8.x-1.x-dev/ 8.x-1.7.

Unfortunately i cannot push to the existing Merge Request.

Looks like the error was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff). could be caused by a broken / empty src in the script tag. <script type="text/javascript" src="/"></script> tag.

Same error was mentioned here: https://www.drupal.org/project/advagg/issues/3374329 🐛 Refused to execute script from /files/js/js_yvkkgN0iKZ30AdwlfXvVMCtPnsFwBKc9nQ8FkcPYRzY.js because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled. Active

@leslie.cordell
Thanks for supplying a patch.
I'll have a deeper look at it, when i find some time after my holidays. But the code looks fine so far..

Since nearly a year passed since your last comment, i wonder, if there is any progress in the issue.
@bradkones1: Did you find time checking the patch / rolling a new release fixing the problem?

Thx in advance.

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

Oh - looks like a C&P issue. Thanks for the finding and your MR.
Committed to latest 1.0.x-dev.

I've updated the patch and added a hook_update_n to set the default value to '_never'.
To keep settings consistent with purge_finished settings, we should not use 0 here, because this is used as immediatly value there.

Since simple_sitemap 3.x is no longer supported, it would be nice, if you could release a new 6.x version, which would support 3.x and 4.x (3.x for backwards compatibility (even if its no longer supported))..

Thanks 💚 :)

Since this issue is RTBC, it would be nice to get the MR merged for a new 8.x-2.x-dev release / in case of having compatibility issues, a new 3.x branch would also be nice to compatibility of Drupal >=9.5 ..
Thanks.