Add support for AI submodule "ai_translate" FieldTextExtractor plugin

Created on 12 June 2025, 2 days ago

Problem/Motivation

The AI module's submodule "ai_translate" provides content translation service through AI.
It provides a plugin called FieldTextExtractor, which allows it to extract textual data from different kinds of field types, in order to pass those to an AI service for translation.

Textual subfields provided by the custom_field module do not get translated through that mechanism, because there is no support for it in this module.

Steps to reproduce

- Install custom_field, ai & ai_translate modules
- Set up a custom field with textual data
- Try to translate an entity containing this field, via the AI translation mechanism

πŸ“Œ Task
Status

Active

Version

3.1

Component

Code

Created by

πŸ‡§πŸ‡ͺBelgium svendecabooter Gent

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @svendecabooter
  • πŸ‡§πŸ‡ͺBelgium svendecabooter Gent

    Linking issue in AI module, that complicates this functionality.

  • πŸ‡§πŸ‡ͺBelgium svendecabooter Gent
  • πŸ‡ΊπŸ‡ΈUnited States apmsooner

    I assume we would need to create our own plugin for field type 'custom' similar to these: https://git.drupalcode.org/project/ai/-/tree/1.2.x/modules/ai_translate/....

    Would have to loop over the subfields and check for subfield translatable setting, max-length, etc... This is all doable but I don't know alot about the AI module yet and how exactly this works so if you want to take a stab at a patch, I'd be happy to review it.

  • πŸ‡§πŸ‡ͺBelgium svendecabooter Gent

    Thanks for the feedback. I'm working on a fix. Might take me a few days to push some code though...

  • πŸ‡§πŸ‡ͺBelgium svendecabooter Gent
  • πŸ‡§πŸ‡ͺBelgium svendecabooter Gent

    OK I think this should be doable, but it would require the patch in ✨ Don't hardcode 'value' key for textual field translation Active to be committed first.
    Not sure how fast that can happen, so this extra plugin probably won't be committed into custom_field, before that issue is resolved.
    I'll try to get the MR here working in combination with that issue, and hopefully keep it as simple as possible.

    Currently there is some logic that checks if a custom_field subfield / property is translatable or not.
    But ideally that should check if that subfield is textual or not. Is there some mechanism in place to do that?
    I guess just doing checks on CustomFieldType plugin instances? I.e. StringType & StringLongType?

  • πŸ‡ΊπŸ‡ΈUnited States apmsooner

    Thats probably the simplest way. There's technically other subfield types like LinkType that has a title property if you wanted to account for that and more complex types (MapType, MapStringType) but the widgets for those are a bit more complex so you way want to just keep it simple for now.

  • πŸ‡ΊπŸ‡ΈUnited States apmsooner

    Oh and the ImageType has title/alt fields. You could also loop over the property definitions (skip the computed) and account for DataDefinition class of string. The only field that differs there is the StingLongType as it has a custom class to make it work with jsonapi and such. You would still want to check for the subfield being translatable along with these checks. They won't be exposed otherwise and inherit the default language value.

Production build 0.71.5 2024