fix(mcp): las traducciones de vars de modulo van por NOMBRE de var, no columna fisica

Una sesion real del agente guardo title3/title6/title2 (columnas de
builder_custom segun varsMeta.fieldName, como decian las docs) y el front
no pintaba nada: el runtime traduce vars con t($record, $var) por nombre
de var. Corregidas descripciones de set/get_record_translations, docs
03/09/11b y ACAI_ENDPOINTS; ademas el puente PHP ahora rechaza titleN/
textN sobre builder_custom con error explicativo (guardrail).
This commit is contained in:
Jordan Diaz
2026-07-17 08:18:18 +00:00
parent 76a63ce4e4
commit 9c3d9fb999
6 changed files with 10 additions and 10 deletions

View File

@@ -389,7 +389,7 @@ Notas: `prefix === "www"` es el idioma base (URLs sin prefijo, `urlPrefix === ""
Notas:
- Solo campos traducibles: `textfield`, `textbox`, `wysiwyg`, `codigo`, `multitext` (el multitext se traduce como el JSON serializado completo en una fila).
- Un `fieldValue` vacío (`''`) borra la traducción y el runtime cae al idioma base.
- Vars de módulo: usar `tableName: 'builder_custom'` + el `recordNum`/`fieldName` que da `varsMeta` de `get_module_config_vars`.
- Vars de módulo: `tableName: 'builder_custom'` + `recordNum` de `varsMeta` (`get_module_config_vars`), pero el fieldName es el NOMBRE DE LA VAR del builder.json (`titulo`, `subtitulo`, `enlace_anchor`...), nunca la columna física `titleN`/`textN` (la action la rechaza con 400).
- Lectura traducida en línea: las tools `list_table_records`/`get_record` pasan `options.translates = <prefix>` al `cmsApi` get (equivalente al header `X-ACAI-ACCEPT-LANGUAGE` en cms_api v3).
## Patrones Comunes