borisson_ → credited valthebald → .
@aolivera: thank you, fixed!
Just a small note for the future: it's better to use branch that is named after the issue number (i.s. 3506263-something) instead of 1.0.x on a separate git origin - that makes local distinction easier
Adding contribution
@jibla: it turns out that function calling is not yet supported by google-gemini-php. There is a PR https://github.com/google-gemini-php/client/pull/67 against beta branch, but not merged yet.
Should we park the issue until PR is merged, or switch to vanilla Guzzle requests as suggested in related Google Vertex issue https://www.drupal.org/project/ai_provider_google_vertex/issues/3506263 🐛 Vertex provider uses PredictionServiceClient and slows down response time. Active ?
valthebald → created an issue.
As @andypost mentioned in #7, the issue is about 2 variants of transcribing "щ" character that are found in the core.
From several sources I've checked, "shch" variant is more "favourable", so I'd suggest use it consistently in all places
Going to work on this during DDD25
valthebald → created an issue.
kristen pol → credited valthebald → .
kristen pol → credited valthebald → .
ericgsmith → credited valthebald → .
Bumping the target version
valthebald → created an issue. See original summary → .
Changed the version
Merged, thank you!
valthebald → created an issue.
Can this be merged to 1.1.x as well?
Bumping the version
Bumping the version + MR is not mergable at the moment
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:
- 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
- line 137: "The actual task, will support files later." should be "The actual task will support files later." (unnecessary comma)
- Drupal\ai_agents\Attribute\AiAgent.php line 11 "The ai provider attribute" AI should be capitalized.
- 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