>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3613861. --> Reported by: [abhisekmazumdar](https://www.drupal.org/user/3557964) Related to !4 >>> <h2>Problem/Motivation</h2> <p><code>ai_answers.agents</code> stores per-agent settings, including two user-facing strings: <code>no_answer_message</code> and <code>answer_prompt</code>. Both are declared in <code>config/schema/ai_answers.schema.yml</code> as <code>label</code> and <code>text</code> respectively, so they inherit <code>translatable: true</code> from core's base data types.</p> <p>In practice neither is reachable through the Configuration Translation UI. <code>ai_answers.agents</code> is declared <code>type: config_object</code> &mdash; simple config, not a config entity &mdash; and simple config only appears in Config Translation when a module explicitly declares a mapper for it. This module declares none. A multilingual site cannot add a language override for the no-answer fallback message or the extra generation prompt.</p> <p>The two sibling AI-ecosystem modules this project depends on both already solve this correctly for their own simple config, and both use the same mechanism: a declarative <code>MODULE.config_translation.yml</code> file, exactly matching core's own convention (see <code>system.site_information_settings</code> in <code>core/modules/system/system.config_translation.yml</code>, which maps the simple config object <code>system.site</code>):</p> <pre><pre>ai_context.config_translation.yml:<br>ai_context.settings:<br>&nbsp; title: 'AI Context settings'<br>&nbsp; names:<br>&nbsp;&nbsp;&nbsp; - ai_context.settings<br>&nbsp; base_route_name: ai_context.settings</pre></pre><p>This is the standard, minimal way to expose a simple config object to Config Translation &mdash; no PHP hook required. <code>ai_answers</code> has no equivalent file, which is the concrete gap this issue proposes to close.</p> <p>Separate note on the <code>ai_agent</code> config entity (from the <code>ai_agents</code> dependency), for anyone comparing notes: it also appears in the Config Translation list, but through a different, unrelated mechanism &mdash; <code>ai_agents</code> registers a <code>#[ModelOwner]</code> plugin with the <code>modeler_api</code> module, and <code>modeler_api</code>'s <code>EntityHooks::entityTypeBuild()</code> sets the entity type's <code>edit-form</code> link template as a side effect of that visual-modeler integration, which is what core's generic config-entity discovery keys off. That's incidental to <code>ai_agent</code> being a config entity with modeler support, not a pattern <code>ai_answers</code> can or should replicate &mdash; <code>ai_answers.agents</code> is simple config, and the <code>MODULE.config_translation.yml</code> approach above is the right and sufficient fix regardless.</p> <p>Worth noting separately: <code>no_answer_message</code> is only substituted on the non-streaming JSON answer path (<code>AnswerService::answer()</code>), not on the SSE/streaming path the block UI actually uses. That's a related but distinct gap &mdash; flagging it here so a fix considers both together, but the scope of this issue is the missing translation mapper.</p> <h2>Steps to reproduce</h2> <ol> <li>Enable a language other than the site default and enable the Configuration Translation module.</li> <li>Configure an AI Answers agent and set a custom "No-answer message".</li> <li>Visit <code>/admin/config/regional/config-translation</code>.</li> <li>Observe that AI Answers agent settings do not appear in the list of translatable configuration, even though the block settings for the Question/Answer blocks do.</li> </ol> <h2>Proposed resolution</h2> <p>Add <code>ai_answers.config_translation.yml</code>, following the exact pattern already used by <code>ai_context</code> and by core's own <code>system.config_translation.yml</code>:</p> <pre><pre>ai_answers.agents:<br>&nbsp; title: 'AI Answers: per-agent settings'<br>&nbsp; names:<br>&nbsp;&nbsp;&nbsp; - ai_answers.agents<br>&nbsp; base_route_name: ai_answers.agents</pre></pre><p><code>ai_answers.agents</code> is already a registered route (<code>ai_answers.routing.yml</code>, <code>/admin/config/ai/ai-answers/agents</code>, the agents overview form) with no required route parameters, so it's a direct fit for <code>base_route_name</code> &mdash; no new route needed. <code>ConfigTranslationFormBase</code> walks the schema tree generically, so the nested <code>sequence</code>/<code>mapping</code> structure of per-agent settings (including <code>no_answer_message</code> and <code>answer_prompt</code>) is rendered correctly without further code.</p> <h2>Remaining tasks</h2> <ul> <li>Add <code>ai_answers.config_translation.yml</code> as shown above.</li> <li>Manually verify the Config Translation UI renders a sensible per-agent translation form given the sequence/mapping nesting (confirm no adjustment is needed, e.g. via <code>properties</code> keys, the way <code>ai_context.config_translation.yml</code> uses them for finer per-field labels).</li> <li>Add test coverage confirming the mapper appears in the Config Translation listing and that a translated value is served for the correct langcode.</li> <li>Separately confirm (or file a follow-up for) whether <code>no_answer_message</code> should also be surfaced on the streaming/SSE answer path, not just the JSON path.</li> </ul> <h2>User interface changes</h2> <p>Adds an entry for AI Answers agent settings to the Configuration Translation listing at <code>/admin/config/regional/config-translation</code>. No other UI changes.</p> <h2>API changes</h2> <p>None.</p> <h2>Data model changes</h2> <p>None &mdash; schema already marks the relevant fields translatable; this only adds the missing UI mapper.</p>