ADR-0007 · Nombres de campo en inglés, etiquetas en español¶

Estado: aceptado
Decisores: responsable de TI de Compulandia
Fecha de la decisión: 2026-09-17

Contexto y problema¶

Las colecciones propias de este repositorio nombran sus campos de dos maneras distintas. banners los nombra en español —titulo, imagen, imagenMobile— salvo dos que quedaron en inglés. sliders, el global main-navigation y los campos reutilizables linkConfig y ctaButton los nombran en inglés. Las etiquetas que ve el editor, en cambio, están en español en todas.

La mezcla salió a la luz al planificar los menús de la historia #299, que crea dos colecciones nuevas y hay que nombrar desde cero. El primer borrador del plan recomendó español mirando solo a banners, sin reparar en que cada entrada de menú contiene un grupo linkConfig, cuyas claves internas son inglesas y se comparten con banners, sliders y botones. Con nombres en español, un mismo objeto de la API quedaría mezclado por dentro.

La restricción de fondo es que renombrar linkConfig es caro: lo usan cuatro funcionalidades y su gramática ya está documentada en RF-005. No se va a cambiar.

Opciones consideradas¶

Nombres de campo en inglés y etiquetas en español en todo lo nuevo.
Nombres de campo en español en todo lo nuevo, siguiendo a banners.
Unificar todo el repositorio en una sola convención, renombrando lo existente.

Decisión¶

Se adopta la opción 1: los nombres de campo se escriben en inglés y las etiquetas del panel en español.

El argumento decisivo es que los campos reutilizables ya son ingleses y no van a cambiar. Cualquier colección nueva los contiene, así que nombrar en español produce objetos mezclados por dentro, que es peor que cualquiera de las dos convenciones aplicada entera.

A eso se suma que el consumidor de esos nombres es siempre desarrollo. El editor no los ve nunca: ve las etiquetas, que siguen en español, junto con el resto de la documentación y de la comunicación del equipo.

La opción 3 se descarta por costo y beneficio. Renombrar banners obliga a migrar datos en producción y a tocar el storefront, a cambio de prolijidad. La mezcla que queda es de una sola colección, y esta decisión frena su avance.

Consecuencias¶

Positivas¶

Un objeto de la API queda parejo por dentro, y quien consume la API lee una sola convención.
La decisión se resuelve antes de que existan las tablas, que es cuando cambiar de opinión es editar un documento en lugar de migrar datos.
Se alinea con lo que el storefront ya tipa hoy en navigation-service.ts, que es inglés.
No afecta a quien carga contenido: las etiquetas, la documentación y los procedimientos siguen en español, según [[lenguaje claro]] ya establecido para el equipo.

Negativas / deuda asumida¶

banners queda como excepción permanente, con sus campos en español. Quien lo lea por primera vez va a encontrar la convención rota justo ahí.
Al escribir código hay que traducir mentalmente entre el nombre del campo y la etiqueta con la que se lo llama en las reuniones y en los documentos. badgeText es "etiqueta", isVisible es "visible".
Un editor que alguna vez mire la API cruda, o un mensaje de error que nombre el campo, se encuentra con inglés. Es poco frecuente pero pasa.
La decisión no arregla la mezcla existente, solo la frena. Sigue habiendo dos convenciones en el repositorio.