🇧🇬Bulgaria @valthebald

valthebald → created an issue.

valthebald → created an issue.

@dmundra: thanks for the update! Checking soon

I've made several commits to the repo with the following results:

• Added cache tags to the calendar view. That fixed stale cache when issues are added/updated
• Added d.o. userid field to contributor content type. This reduced the number of calls to the API
• Added static caching of user and node data when processing a project
• Added drush commands to process single module and all modules
• Process single module configuration using Drupal queues. First thing that is done by drush command is populate the queue, so even if the drush command fails for any reason, the queue can be processed later
• Handle "429 Too many requests" responses from API (up to 3 retries with 30 seconds delay before finally giving up)
• Added contributor now shows in the dashboard

Regarding timeouts, the proper way to overcome this would be to run the imports in scheduled cron jobs, but unfortunately, DF does not support that yet.

Duplicates ✨ Content moderation options in entity translations Active

@anjaliprasannan: I could reproduce the issue locally with the latest 1.2.x, and your patch fixes it.

Merged to 1.2.x, thank you!

sorry for the spam

and another update

Assigning to myself to check how issue assigning works on AI dashboard

I get this error: TypeError: Gemini\Data\GenerationConfig::__construct(): Argument #6 ($topK) must be of type ?int, float given, called in /var/www/html/web/modules/custom/gemini_provider/src/Plugin/AiProvider/GeminiProvider.php on line 260 in Gemini\Data\GenerationConfig->__construct() (line 39 of /var/www/html/vendor/google-gemini-php/client/src/Data/GenerationConfig.php).

(probably related to the signature change in the library between the versions).

Steps to reproduce:

1. Enable AI Explorer module
2. Go to AI Explorer > Chat generation
3. Select any tool

Here's my configuration:

Going to check this today and report the results

valthebald → created an issue.

kristen pol → credited valthebald → .

Merged with 1.2.x, thank you @Aporie!

Added some comments on PR (first one is a deal breaker)

valthebald → created an issue.

Merged with 1.2.x, thank you @anjaliprasannan

@ralkeon: can you please create a merge request? and what is your overall configuration (i.e. steps to reproduce)
Thank you!

We can use ✨ Add text extractor plugins for image and link field types Active as a starting point. With the new base class for field extractors, adding a new one for address field should be quick.
Also, bumping version

I don't think we need to wait until 2.0 to have this feature, downgrading target version

I like the idea, only small changes in MR please

@anjaliprasannan: I don't think so. LB itself has own abstraction layer and does not depend on block_content.
The issue is ai_translate-specific, and should be fixed in LB extraction plugin

valthebald → created an issue.

valthebald → created an issue.

@Aporie nice touch!
Can you please review the messages in https://git.drupalcode.org/issue/ai-3536092/-/jobs/5926826, and also ensure that the code applies to 1.2.x? Since this is schema changing, we probably need an update hook to change existing configurations, especially is this will be backported to 1.1.x

This issue has bothered me "in the background" for some time, only to realize that translations actually can be set to unpublished even when the source entity is published, so this is handled by content moderation module somehow.

So I debugged what happens in content moderation module and added the same code to AiTranslateController.

Please review

LGTM

@marcus created 📌 Move TextExtractor service to AI core Active and assigned to myself. Will try to submit a proposal by Monday EOD

valthebald → created an issue.

@svendecabooter I haven't experienced this, will check

valthebald → created an issue.

@svendecabooter: done! Thanks for pointing this out

Committed to 1.2.x only because of the new method getColumns() in FieldTextExtractorInterface
Thanks everyone!

Copying from Slack:
Having a base class for text extractors sounds good (and it's really easy to add a new plugin!)
One thing I didn't understand is why change FieldTextExtractorInterface?
i.e. passing an entity in extractor constructor instead of setValue(), extract() etc. calls means that we need extractor instance per field per entity, when in the current state, it's extractor instance per field type

@apmsooner: I am back from vacation, and will review this MR ASAP

@balazswmann technically, it does, but you can't use gemini as a chat with tools.
@jibla do you need some help with that?

valthebald → created an issue.

valthebald → created an issue.

Fixed in 1.1.x, 1.2.x and 2.0.x with https://git.drupalcode.org/project/ai/-/commit/26d58a45ce4408afadafec7b6...
and

Also, bumping version - no sense in having it in 1.1.x that is in bugfix-only mode

@apmsoon: good, thanks for clarification!

I feel that we're stuck somehow, would it make things easier to split this issue into multiple (by field type)?

It looks like core bug prevents such behavior - when creating a new translation with enabled content moderation, "published" key is set to all translations based on the "moderation_state" field.

Postponing until 🐛 New translations for moderated nodes are not created in the initial workflow state Needs work is resolved

Closing this since no steps to reproduce and probably fixed elsewhere

valthebald → created an issue.

valthebald → created an issue. See original summary → .

Can't reproduce it with the latest 1.1.x or 1.2.x
Is this still relevant?

After some debugging, the reason for the status being kept as "Published" is \Drupal\content_moderation\EntityOperations::entityPresave() that checks $entity->moderation_state field but not the "published" key (which is changed indirectly.

Needs to be tested how this affects the published status of original entity (it should stay intact)

@efpapado: there could be an option to match both flows, and this is "let the user decide" option in
AiTranslateSettingsForm::buildForm (see the second MR):

      '#options' => [
        'keep_original' => $this->t('Keep the status of original entity'),
        'create_draft' => $this->t('Create translation in draft status'),
        'user_decision' => $this->t('Let the user decide'),
      ],

but in any case, non-unpublishing the translation is the bigger target to hit

@efpapado: we could argue on possible reasons to change the flow, but there's more:
1. UI change - "Translate using ... " already takes significant part of the translation list screen, if we have 2 options instead of one, the screen would look like this:

This doesn't seem an improvement of UX. Maybe those options can go to the actions list (Add/Edit/Delete)?
2. More importantly, "force save unpublished" doesn't take any effect, I still get a published entity if the original entity is published.

Also, bumping target version

I see some common approach with how AI translate module extracts textual data from (sometimes nested) entity fields - there is FieldTextExtractorInterface introduced in https://www.drupal.org/node/3464024 → and TextExtractor service that has extractTextMetadata/insertTextMetadata methods.

Can this be reused in content suggestions?

That would require some (minor) changes like moving the service and field plugins from ai_translate to ai module itself, but benefit IMO is bigger

@efpapado: oh, I didn't realize that.
Still, I'd prefer the approach in https://git.drupalcode.org/project/ai/-/merge_requests/696 - I don't think it's the site builder who decides what is the translation flow (i.e. is the AI-translated page gets published), but the site administrators.

valthebald → created an issue.

kristen pol → credited valthebald → .

@efpapado: I'm afraid your approach creates an option to permission bypass, i.e. by manually adding 1 to the link, user will be able to publish an entity even if they don't have access to

I have the same behavior as @anjaliprasannan