Een hart voor de Drupal Community

Apologies, the last patch missed some changes to the entity's interface.

Another possible edge case would be if one entity's field is translatable and the other isn't, then the one to many relationship should also be reworked so it updates all translations of the translatable entity rather than just the current translation.

I updated the MR to allow one-to-many translation relationships.

I can reproduce the issue you're talking about, furthermore I also run into an issue where the values are added to the default translation of the corresponding entity.

I added a merge request that fixes these issues for me locally.

It: - Retrieves the translated version of the original entity, if it exists - Retrieves the translated version of the referenced (corresponding) entity, if it exists

This should also not affect untranslated fields, if the field is untranslated and you retrieve a translation of an entity, the values will just be saved to the default translation.

I also added a static patch of the MR in its current state.

randalv made their first commit to this issue’s fork.

Thank you!

It's a minor but important change.

All the best, Fons

You can see it in action on my live site here:

https://webhaven.io/documentation/theming/theme-structure

Hi @loparev,

The code still needs an improvement for translating locale strings, it's not an entity so context can't be send to Smartling. We receive this error in the logs: Failed to alter contextUrl= with the following message: The "default" entity type does not exist.

Maybe just check if the entity type exists? https://git.drupalcode.org/project/tmgmt_smartling/-/blob/8.x-9.x/tmgmt_...

Problem/Motivation

As a followup to #3549657: AI CKEditor: use prompt entities instead of custom configurations, I noticed the ai_ckeditor prompts are stored in global settings for the module. However, other settings (such as the selected provider) are stored in the AiCKEditor plugin settings, on a per filter_format basis.

Is there a specific reason for this? And is that reason still valid after prompts are stored as ai_prompt entities, rather than just textual prompts in config?

It might be interesting to store a reference to the selected ai_prompt entity on a per filter_format basis. That way, users can decide to provide alternative prompts, based on the filter format that is chosen.

Especially since the AI provider can also be changed per filter format, it seems logical you might want to provide a different prompt per filter format as well (e.g. to tailor it towards the selected AI provider).

@loparev, you are correct, we weren't using the new metatag_computed field. We're also looking in detail why the other fields are still there, but it should also be somewhere in our part of the configuration. I close the issue when we get this validated by our client. Thanks!

Problem/Motivation

At the moment whenever a piece of code is wrapped in a code block the library is automatically used.

I don't think that's desirable.

You would want to have it fired on code block (pre code). But you also want to be able to add inline code like this in a text where you don't want to use this library.

Steps to reproduce

Add code blocks with and without pre around it and you'll notice the library is always fired.

Proposed resolution

Alter the JS so it's only fired on pre code.

f0ns created an issue. See original summary.

Problem/Motivation

In https://www.drupal.org/project/ai/issues/3549153 we changed the configuration schema for storing prompts in the ai_translate module. Instead of having the actual prompt text (default + prompt text per language) stored in configuration, we store a reference to an ai_prompt config entity.

I haven't tested yet if this will break this module, since it extends the ChatTranslationProvider from ai_translate. If it does break things, a fix will need to be implemented for support with the upcoming ai-1.2.0 stable release. If it does not break things, it might be good to alter the logic of this module, to also use ai_prompt entities, for consistency with the main AI module.

The fix doesn't apply anymore in the latest upgrade to Drupal 11.2.5, I'll look into it.

So the daily bucket works by reusing old jobs for new entity updates, the job items contain copied field values from the entity.

The issue we have is that we updated field configuration to be excluded from tmgmt translation, and it is still being send for translation by the daily bucket.

We had the issue with https://www.drupal.org/project/tmgmt/issues/3485924. The tmgmt module update got installed on 18/11/2024 and we experience this still today:

tmgmt_sources/JobID14167_en_en-US.xml:                                                    <span sl-variant="media-33808-metatag][0][tag" class="atom" id="bNTc0NDNdW21ldGF0YWddWzBdW3RhZw">meta</span>
tmgmt_sources/JobID14167_en_en-US.xml:                                                    <span sl-variant="media-33808-metatag][1][tag" class="atom" id="bNTc0NDNdW21ldGF0YWddWzFdW3RhZw">link</span>

It also causes issues with plugin IDs and rabbit hole (see screenshots), which breaks functionality completely. So we fixed our part but are still stuck with old cached data in the job items that get reused.

You mentioned that there should be a way to update the old job item data with new updated configuration/content. An alternative solution for the daily bucket would be to create a new job containing completely new job items, that would prevent the issue as well.

bceyssens created an issue.

bceyssens created an issue.

Similar to https://www.drupal.org/project/tmgmt/issues/3485924 but then for the fields create by rabbit_hole module.

Problem/Motivation

Add Gitlab CI integration, to better monitor code quality.

Problem/Motivation

Add support for Drupal 11.

@loparev they agreed that they need to clean the old pending jobs. Reading the API responses, we assumed that the jobs were already translated/completed but that's not the case. Have you ever thought about switching the process around and only try fetching translation from unfinished tmgmt jobs? Closing as it isn't an issue.

Hi @loparev, glad we're making progress here!

Triggering cron via the UI is possible, but will it ever be used that way on production environments? If I'm not mistaken, everyone using CLI to process the queues will run into the authentication issue, unless using the default tmgmt functionality.

The above works fine with the tmgmt anonymous_access expect if you really need to support uploading context for Drupal setups that have the "View published content" permission disabled.

So I think you need to decide which of these 2 ways of working you want to support in the module. If you get the authentication working, that would be even better!

bceyssens created an issue.

I think uploading all of these assets one by one also makes the process incredibly slow. Why not use Guzzle http client instead of curl commands directly after which you could easily execute async upload commands for all of those assets: https://docs.guzzlephp.org/en/stable/quickstart.html#concurrent-requests