🇧🇬Bulgaria @valthebald

valthebald → created an issue. See original summary → .

@vivek panicker: I tested with core 10.4 and ai 1.0.x, and it worked for me. Can you provide more details about your configuration? Are variation fields marked as translatable with AI? Another place to check is AI translate settings /admin/config/ai/ai-translate, especially entity reference section

valthebald → created an issue.

@marcus_johansson can this be merged to 1.1.x as well please?

@vivek panicker: I have asked ChatGPT and Gemini to analyze and find possible grammatical mistakes in the source code of ai_agents, and here are some other places to fix/improve:

1. AiAgentExplorerController.php line 84: "Check if its a json response." Should be "Check if it's a JSON response." (capitalize JSON and add an apostrophe
2. line 137: "The actual task, will support files later." should be "The actual task will support files later." (unnecessary comma)
3. Drupal\ai_agents\Attribute\AiAgent.php line 11 "The ai provider attribute" AI should be capitalized.
4. Drupal\ai_agents\Form\AiAgentPromptChanger.php line 13 "Configure on AI Agent." sounds confusing and misleading

I wonder if those should be handled in the same or separate issue?

@mrdalesmith: simple and effective! Nice catch, marking RTBC

Bumping the version + suggest more generic approach

Changed the documentation of translate text call

@mrdalesmith: The issue this patch tries to solve: out of the box, with AI module alone or AI recipe in Drupal CMS), users have "Translate text" operation type on the settings screen, and the list of providers that implement this operation type, is empty.

Which is confusing, and the most frequent question I get from the new users trying to use AI translation capabilities, is why they cannot use OpenAI or Claude for translation.

By "any other you might be using", I am aware only about deepl implementing "Translate text" operation, and this is not mentioned on the AI settings screen.

valthebald → created an issue.

Closing since meetup was cancelled

Passes now

@scott_euser: I tried to address all you remarks in gitlab:

1. Clearer hook_requirements()
2. Handle case for null source language
3. Model selection on the AI settings screen
3. hook_update() that sets default translate provider when it's empty

Can you check if you still get escaped HTML?

valthebald → created an issue.

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

valthebald → created an issue.

@dunx, those are exactly the steps to confirm the patch is working, thank you!
I dare move it back to RTBC (I know, formally I shouldn't do it as a patch author, but there was no change in the code, only clarification of the review process)

jurgenhaas → credited valthebald → .

@dunx: You get published translation with applied patch too?

With symfony mailer, you can use Sendgrid as sending transport as described here https://www.drupal.org/project/sendgrid_integration/issues/3256519 ✨ Compatibility with Symfony Mailer Closed: works as designed .

That way you just use default contact form

When translated entity implements EntityPublishedInterface, keep the published status from original entity.

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

Fixed links to issues

valthebald → created an issue.

jurgenhaas → credited valthebald → .

jurgenhaas → credited valthebald → .

valthebald → created an issue.

@mrdalesmith: this issue is not about consent management in general (this should be handled elsewhere, and Drupal CMS is going to use Klaro → manager for that), but about getting user consent when data is sent for external data processing by the provider.

For locally hosted providers like llama, this is not an issue, but when a user communicates with (as an example) a chatbot, they need to be aware their input may be sent outside of the website.

valthebald → created an issue.

Looks good to me, thanks!

I faced the same issue and was going to suggest a similar fix :)
Patches fixes the issue, yet I have a small suggestion (wrote in gitlab)

I have created https://www.drupal.org/project/solrlog → as a separate project, to allow installations without patching search_api_solr

jurgenhaas → credited valthebald → .

Add reference to valthebald/ddev-matomo ddev plugin

@jan kellermann I'm equally amazed by your knowledge of the EU laws as I am disappointed by implied restrictions to deliver meaningful functionality to our clients...

jurgenhaas → credited valthebald → .

As far as stickyHeaderState is entirely client-processed and is not collected/processed by the server (who should it be?), I'd argue it's not a subject to GDPR or similar regulations.
GDPR, as it states in the very first article, is about

...rules relating to the protection of natural persons with regard to the processing of personal data and rules relating to the free movement of personal data.

since there is no processing of personal data, I'd say there is no need to get user consent

jurgenhaas → credited valthebald → .

jurgenhaas → credited valthebald → .

jurgenhaas → credited valthebald → .

Fixed most of the comments (2 left are for the future).
Also, brought back editing of default translation prompt (patch to have per-language left it hidden) and display of default prompt that has a condition

I suggest to mark this a duplicate of 🐛 [pp-3] Bubbling of elements' max-age to the page's headers and the page cache Postponed and 🐛 Views' cache with relative date filter is not invalidated when needed Active

@mkalkbrenner did you have a chance to check this?

Tested and works for text fields attached to entity being translated and referenced entities

valthebald → created an issue.

valthebald → created an issue.

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

Solr-based logger mimicking dblog UI - https://www.drupal.org/project/search_api_solr/issues/3475570 ✨ Provide Search API-based alternative to dblog Active

valthebald → changed the visibility of the branch 3475570-solronly to hidden.

valthebald → changed the visibility of the branch 3475570-logger to hidden.

@mkalkbrenner sure, I will create a MR later today

@mkalkbrenner: PoC of lighter, Solr-only logger implementation https://git.drupalcode.org/sandbox/valthebald-3476169
TL;DR; where possible, I followed dblog patterns, replacing database specifics with solarium queries

valthebald → created an issue.

marcus_johansson → credited valthebald → .

Finally had some time to work on this.
@Marcus_Johansson:
1. I have added a third party subform to Field UI's FieldConfigEditForm:
2. Defaults lead to AI translate settings form

@yonailo: I noticed (and fixed) some PHP messages coming from changes in the upstream, hopefully this fixes your case.
If not, please provide more details

@yonailo what errors do you get?

phpcs is good now for https://git.drupalcode.org/project/ai/-/merge_requests/40

✨ (ai_translate) One click translations for Layout builder Active can't be resolved before this one, both issues can be either fixed together, or this one is committed earlier (possible?)

Totally agree with #22
In any case, having complex conditions like the one from #20 goes beyond the scope of this issue

@W01F I doubt such a flexibility can be achieved using single prompt, but be addressed in a more generic solution ( ✨ [META] Create a reusable "Prompt Entity" and field Active seems natural umbrella)
I.e. when translating a taxonomy term that has layout builder blocks or paragraphs, what would be an entity type context?
I suggest to use this specific issue as a proof of concept, and then work on a more generic solution in another issue. What do you think?

I have enabled the plugin, and got this far -
but when I click "Save changes to editor", this simply clears selection text

Since the documentation is growing (and it makes sense!), I am going to offload this to a new help topic

Addressed concerns from #11:

1. Processing every piece of content in a separate batch operation to avoid timeouts
2. Text fields are now translated only when the field is translatable
3. The (officially unsupported) case of translatable paragraphs reference is not handled and raises errors.

Added link to Twig documentation on d.o., added validation of prompt twig

I really liked suggestion to use Twig for prompts :)
What is done in this MR:

• Added ai_translate.settings simple config object and provided default value in config/install
• Added hook_update_N() to have the config for existing installations
• Added configuration form to edit the prompt, plain textarea for now
• Switched from hard-coded prompt text to config value in AiTranslateController

Here's what was done:

1. Created new plugin type TextExtractor and accompanying plugin manager for field text extractors
2. TextExtractorInterface has 2 methods: extract() that returns an array of translatable metadata (value + optional format, delta etc.) from entity field, and setValue() that does the opposite and sets translated value back into the entity
3. Created 2 TextExtractor plugins - text (the list of field types supported before) and entity_reference (including entity_reference_revisions)
4. Since entity references can increase the number of texts to translate, translate controller now processes the texts in chunks
5. Created drush command ai:translate that does exactly the same as translate controller, but in one chunk. I know it's possible to process batches in drush as well, but not sure if that was needed

I'm afraid we're over-engineering the starting point.
Visual editing, inheritance and so on of prompts is great, but just for the purposes of being able to change default prompt, even simple configuration entity would suffice.
If aiprompt is not finding its way into "core" ai (or ai's composer.json as dependency) real soon, ai and its submodules cannot rely on the very existence of prompt entity.
As an immediate solution, I would suggest having prompt as a config entity (I am going to try this approach as a PoC for ai_translate and specifically 💬 Can't modify prompt for translating Needs review )
aiprompt can add visual editing, separate ConfigEntity class etc., but "core" ai should have something to start with

@mindaugasd: by next release, do you mean next release of aiprompt or of ai?

Probably related to ✨ [META] Create a reusable "Prompt Entity" and field Active ?
We can provide default starting prompt instead of hard-coding it in the module

Updated the fork following the interface change in 1.4.5

Thank you all!

Thank you all!

Thank you all!

This https://git.drupalcode.org/project/ai/-/merge_requests/37/diffs is not ready for the prime time yet, but done some preparation:

1. Text extraction from entity fields is not done with plugins (of type FieldTextExctrator)
2. Extraction of field types supported currently (hard-coded in $allowed_types variable) is moved to TextFieldExtractor, which is the only plugin so far
3. Next step is creation of ReferenceExtractor plugin that will support entity reference and entity reference revisions
4. After that, add the batch creation when the number of extracted texts to translate exceeds certain level. Not sure if this should be done in the same or separate issue.
5. To mitigate possible need of batch, create a drush command that will create a translation

I will try to provide some PoC (including batches) tonight

Shouldn't translation of paragraphs/blocks be the part of translating the host entity? I would add entity reference (and entity reference revision as a subclass of it) to the list of supported field types when translating the entity