🇧🇬Bulgaria @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 #2352009: [pp-3] Bubbling of elements' max-age to the page's headers and the page cache → 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

...and it exists, actually! ✨ (ai_translate) One click translations for Paragraphs Needs review

Linking ai_translate issue

@anup.sinha that was the first thing on my mind after seeing initial patch :)
I believe we should have a separate issue for that

@Marcus_Johansson: I've added a few comments, none of them are show stoppers

Am I the only one to suddenly think of webform and its structure/UI?
Component chaining, parameters, plugins, conditionals etc... webform has it all, with stable UI to configure.
Can we borrow some of webform approaches?

I was searching for this issue while fixing ai_translate module :)
Hard-coding the prompts is definitely not the best idea, and doesn't give users much flexibility.
So, what is a prompt? Config entity with token support? In this case, initial prompts are placed in config/install and then configurable at some "prompt UI"?

I get fatal errors with this branch, will provide details (and probable fix) later today

Added paragraph describing the necessity to update entity field definitions

valthebald → created an issue.

@xlyz: I still believe this belongs to commerce_sync rather than this module

valthebald → created an issue.

valthebald → created an issue.

valthebald → created an issue.

valthebald → created an issue.

valthebald → created an issue.

I've submitted my suggestions from #12:

• Removed node as hard-coded entity type, expecting ContentEntityInterface now. AiTranslateRouteSubscriber::alterRoutes() was already adding "Translate with AI" links to all supported entity types.
• Changed signature of AiTranslateController::translate() to AiTranslateController::translate($entity_type, $entity_id, $lang_from, $lang_to)
• Changed permission name to "create ai content translation" and added module's .permissions.yml
• Enabled translation from original to default language (entity is not necessarily created in site default language, but it would be good to have an option to translate from original language to default one)

Performed several tests locally, module worked for me for both nodes and taxonomy terms

Things that are not working yet:

• The only supported base field is label
• All fields are treated as text_format (value + format), including plain text

Both issues do not look to me as deal breakers to include the module to HEAD, but up to you to decide.

I will submit some changes later tonight

I'd put the logic of when to throw the new exceptions (quota/rate) into providers, the core handling them in the unified way

@Marcus_Johansson - what do you mean external module? As in having it's own composer package, or submodule of drupal/ai?

As I said, I'd be glad to help when it comes to the coding part :)
Suggested changes are not that big to postpone them

Moving to Needs work because of comments

valthebald → created an issue.