Een hart voor de Drupal Community

Problem/Motivation

I would like to become a co-maintainer of this module to merge the Drupal 11 compatibility patch along with any appropriate RTBC issues and create a D11-compatible release.

You can view my profile to see my large history of work.

Proposed resolution

Review my profile and, if approved, add me as co-maintainer with appropriate permissions to merge code, manage issues, and create releases.

Remaining tasks

Add me as co-maintainer for this module.

Problem/Motivation

I would like to become a co-maintainer of this module to merge the Drupal 11 compatibility patch along with any appropriate RTBC issues and create a D11-compatible release.

You can view my profile to see my large history of work.

Proposed resolution

Review my profile and, if approved, add me as co-maintainer with appropriate permissions to merge code, manage issues, and create releases.

Remaining tasks

Add me as co-maintainer for this module.

Problem/Motivation

The project page for the AI module has a section "Other modules/recipes that work with the AI module". Can the https://www.drupal.org/project/ai_usage_limits module be added to that?

There is now a first alpha release available. It requires at least a version of AI module higher than 1.2.0-alpha2 (or 1.2.x-dev). So maybe the module should only be added to that list, once such a release is available.

Thanks for your consideration.

Problem/Motivation

It would be good to have the option to manage the client ID / client secret via the Key module, instead of storing it in config. This would increase security.

@loparev I'm not sure if we really need to switch user like the masquerade module does? The tmgmt module added an access bypass feature around the same time context user switching has been added in this project.

anonymous_access is enabled by default, that's probably why it works in most cases? If it is disabled or the key query param is stripped before it reaches the webserver, you'll run into the tmgmt_smartling authentication issue.

• https://git.drupalcode.org/project/tmgmt/-/commit/b28aeb95e70a17fff72df7...
• https://git.drupalcode.org/project/tmgmt_smartling/-/commit/d65e50a8d910...

Those seem like some valid points and good improvements to the AI translation system to me. To implement some of those, some major refactoring might be needed to the AI Translate system, so not sure if they would all be easily doable.

Currently the field data gets extracted from the entity, based on the field type of each field. The 3rd party settings available on a field could be leveraged to configure this some more. E.g. the ReferenceFieldExtractor plugin already does this, to decide whether to translate a certain entity_reference field or not. Extending this with the option to "optionally disable translation per field" seems fairly doable.

An optional prompt per field is something that would need to be passed along in the metadata of the extracted field values, towards the TextTranslator service. This should also be possible, but would complicate the already somewhat complex array structure of this even more.

Switching providers per field would work in the same way. Actually the \Drupal\ai_translate\TextTranslator::translateContent() method already has a context array parameter implying in the documentation that should be possible, but the implementation code doesn't do anything with it.

We should probably provide a decent framework where configurable context can get passed along during the translation pipeline (text extraction, AI service calling, translation saving), and more events get triggered, so other contrib modules could plugin into that and provide extra tools - if not provided with the ai_translate module itself.

I think this request should probably need some more analysis, and be split out into separate subtasks.

Hi @loparev, we're running into the same issue.

We've setup a new Drupal environment to isolate the issue: Drupal: 11.2.2 Tmgmt: 8.x-1.17 Tmgmt Smartling: 8.x-9.17

We've used the context debug submodule which works as advertised. The issue however only occurs when trying to upload unpublished pages, in combination with the queue worker running from command line.

It looks like the code, copied from masquerade, on its own (handled with curl afterwards) doesn't handle sessions completely. Masquerade does a redirect on which the Symfony frameworks handles the session correctly and sets the cookie in a response listener.

To dive deeper into the issue, dumping the cookies from modules/contrib/tmgmt_smartling/src/Context/ContextUserAuth.php's getCookies() looks like SSESSc2b280e207aa821b24606f896b740d6d=. As you can see it lacks the session_id value.

It's probably because the queue is handled via command line (cron)? Let me know if you need more information to reproduce on your end.

anmolgoyal74: can you add this to the MR?

The change in modules/ai_translate/src/Plugin/FieldTextExtractor/ReferenceFieldExtractor.php did fix the issue I encountered on a website, where untranslated fields (eg regular select list) where left blank in the AI translation.

Sven Decabooter added a comment on drupal.org: Error when trying to create an ECA model via AI

Tried a few prompts and I did not get any more fatal errors.

Thanks, this fixes the issue when I reproduced this behavior.

svendecabooter created an issue. See original summary.

Problem/Motivation

I tried clicking the "Ask AI" button, to have it generate an ECA model for me. I didn't save the exact prompt beforehand unfortunately, so I don't have that to reproduce.

The general purpose was like this:

Upon saving a node, create an SEO-friendly summary of the full node display, and fill it in in a designated field. The full node display context was provided via the [node:render:full] token (drupal/token_entity_render module).

After this request, the batch process started, but crashed with the following error:

Problem/Motivation

I tried creating an ECA model that automatically fills in a textarea field on a page node (field_seo_description). It is supposed to take the whole node contents (full view mode), and use AI to create a summary out of that, and fill it in the aforementioned field.

However, when trying to use the "AI automator" action trigger, I'm getting the following error: action "AI Automator Trigger" (eca_ai_automator_1fcddok): The submitted value in the Automator element is not allowed.

Steps to reproduce

Used module versions:

• "drupal/ai": 1.2.0-alpha2
• "drupal/ai_integration_eca": 1.0.0-rc2
• "drupal/bpmn_io": 3.0.0
• "drupal/eca": 3.0.2
• "drupal/modeler_api": 1.0.x-dev
• "drupal/token_entity_render": 2.0.0
• "drupal/schemata": 1.0.0

Configuration for my field_seo_description field:

• “Enable AI Automator”: checked
• Automator type: LLM Text
• Input mode: Advanced
• Prompt:

  Create an SEO-friendly summary of the page content, as provided within the context below.
  The description should be in the same language as the provided body text.
  If the context is not sufficient or empty, please just return an empty string.
  
  Context:
  Title: [node:title]
  Body: [node:render:full]
  

  Body token is provided by the token_entity_render module. It provides HTML output of the whole page. Not sure if this is the best approach, since I'd want only the text, not the HTML, but it's a start...

• "Edit when changed": checked
• “Automator worker”: ECA
• "AI Provider": LLM Proxy (using lite_llm)
• “Joiner”: Space

I created an ECA model, and dragged a start event on it - selecting "Update content entity" (bundle: node page) The action is of type "AI Automator Trigger".

Screenshot:

svendecabooter created an issue. See original summary.

So for example:

\Drupal\ai\AiFieldTextExtractor\TextFieldExtractor:

#[AiFieldTextExtractor(
  id: "text",
  label: new TranslatableMarkup('Text'),
  field_types: [
    'title',
    'text',
    'text_long',
    'string',
    'string_long',
  ],
)]
class TextFieldExtractor {

  /**
   * {@inheritdoc}
   */
  public function getColumns(): array {
    return ['value'];
  }

  /**
   * {@inheritdoc}
   */
  public function extract(ContentEntityInterface $entity, string $fieldName): array {
    // IMPLEMENTATION.
  }

  /**
   * {@inheritdoc}
   */
  public function shouldExtract(ContentEntityInterface $entity, FieldConfigInterface $fieldDefinition): bool {
    return TRUE;
  }

}

(some of these methods would be in a base class obviously, but for illustration purposes I added them here)

and

\Drupal\ai_translate\FieldTextExtractor\TextFieldExtractor:

#[FieldTextExtractor(
  id: "text",
  label: new TranslatableMarkup('Text'),
  field_types: [
    'title',
    'text',
    'text_long',
    'string',
    'string_long',
  ],
)]
class TextFieldExtractor extends \Drupal\ai\AiFieldTextExtractor\TextFieldExtractor: {

  /**
   * {@inheritdoc}
   */
  public function setValue(ContentEntityInterface $entity, string $fieldName, array $textMeta) : void {
    // IMPLEMENTATION.
  }

  /**
   * {@inheritdoc}
   */
  public function shouldExtract(ContentEntityInterface $entity, FieldConfigInterface $fieldDefinition): bool {
    return $fieldDefinition->isTranslatable();
  }

}

I probably was a bit too enthusiastic with my MR.

I identified multiple problems with just moving the FieldTextExtractor plugins from ai_translate to ai core:

1. The logic in shouldExtract() for each plugin is tightly coupled to translation logic. In it's easiest form, it checks if a field is translatable. In more complex cases, e.g. for Entity References, it checks configuration settings to determine whether to extract a given entity reference.
2. The logic in setValue() is also tightly coupled to translation logic. It assumes the plugin that extracted the field value, will store it again on the exact field same location (but on the translated version of an entity)

The scenario's where text extraction could be useful outside of translation logic, seem to be:

• For ai_content_suggestion: this just needs the extraction part, not the logic for setting the value again on the same field!
• For ai_automators: might be useful to provide the extracted values as tokens to automators? There is already something in place like that, but using the extractor plugins might extend that logic? Haven't looked to deeply into this. But this would also only need the extraction logic I assume?
• ... other places?

Refactoring the FieldTextExtractor plugins to be more generic, while keeping backwards compatibility, seems rather challenging. I was thinking we could set it up as follows:

New plugin type: AiFieldTextExtractor

• Resides in the Drupal\ai namespace
• Provides implementations for various field types, same as current ai_translate FieldTextExtractor plugins
• Only implements the methods: extract(), shouldExtract() & getColumns() no value setting logic
• Does it need to be limited to extracting text? If not, name it AiFieldExtractor? Haven't thought this through yet :)

Existing plugin type: FieldTextExtractor

• Resides in the Drupal\ai_translate namespace
• Already has implementations for various field types: they will be refactored to extend their AiFieldTextExtractor equivalent
• Only provides the setValue() method.
• extract() and shouldExtract() could be overridden to provide translation-specific logic that is not in the parent AiFieldTextExtractor plugin counterpart
• Could potentially be deprecated in 2.0.0 in favor of a better named AiTranslateFieldTextExtractor plugin / namespace, but that might be nitpicking on my part...

ai_translate and contrib modules extending this module would keep on using the FieldTextExtractor plugins. Other AI modules could use just the extract logic from the AiFieldTextExtractor plugins, and run with it.

Does that make sense, or is it overly complex and unnecessary? Thanks for giving it some thought.

TODO:

- \Drupal\ai\TextExtractor::shouldExtract() still contains translation-specific logic. This should be moved to the module making use of the Text Extractor service, in this case ai_translate. Not sure how this should be set up.

Added a MR to refactor this. Marked the existing ai_translate classes / services deprecated, so contrib modules extending them, have time to update their dependencies.

Fons added a comment on drupal.org: PageSpeed Insights - Accessibility (ARIA)

Problem/Motivation

Hello, I'm using the FAQ field module on my websites and it's really nice.

I render them with the JQuery accordion formatter.

I've noticed that PageSpeed Insights has accessibility warnings based on the standard implementation.

Steps to reproduce

Setup a FAQ field with formatter JQuery accordion.

Run the PageSpeed Insights tool (https://pagespeed.web.dev/).

You'll see you get a 95 score (if your websites complies on all other points and a notice):

"Elements with an ARIA [role] that require children to contain a specific [role] are missing some or all of those required children."

I've already changed the h3 to a button to see if that helps and some other stuff but I keep getting the warning.

Anyone else has any ideas? Would love to get this fixed.

f0ns created an issue. See original summary.

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

Sven Decabooter added a comment on drupal.org: Translation batch process does not handle translation errors

Setting back to 1.2.x as the correct branch to target.

I tried reproducing this, as I had earlier experienced weird behavior when I had connection problems to my AI API endpoint. However, in my testing, I get into \Drupal\ai_translate\Plugin\AiProvider\ChatTranslationProvider::translateText(), and into the GuzzleException catching. This then logs the error, but proceeds to return an empty translated text output.

This finally results into database errors trying to save the translation, and the display of the message "There was some issue with content translation.".

So the scenario above might be a separate use case that could be taken into account for improving the error message output. The error message should be more clear, and a translation should not be attempted to be created I guess?

Sven Decabooter added a comment on drupal.org: Custom fields without field_ prefix are not extracted for translation

Tested this MR.

I removed all content_translation permissions from a given user. They could no longer see the "Translations" tab in that case.

However, when given the "Create AI translation" permission, they could still access the translation URL directly, and a translation was added. Not sure if this is desired behaviour, or if it should be an AND operation: only create AI content translations when you have "create ai content translation" permission + the appropriate content_translation permission as well.

So the original issue raised in this topic was not yet fixed, AFAIK.

The improved logic to hide the AI Translation column when not relevant, seems to work and is definitely an improvement.

I also took the opportunity to add extra config validation to the schema. This is useful for when ai_translate settings get set via another means than the settings form, e.g. via a recipe.

This also lays the groundwork for simplifying the settings form, by using #config_target for all / relevant form elements.

• Fixed the entity_reference_depth that was wrongly positioned in the default config
• Added missing language_settings default value
• Updated default reference_defaults values. Now it defaults to empty, since it was referencing entity types that might not even exist on a given site, making the configuration valid more of a challenge.

The last change might be debatable...

svendecabooter created an issue. See original summary.