Etiquetas multilingües
GCM viene con inglés, español, francés y portugués como idiomas de interfaz soportados. Las cadenas de la interfaz (etiquetas de botones, elementos del menú, mensajes de error) provienen de los archivos de traducción i18n/locales/<lang>.json mantenidos por la plataforma. Pero los datos — tus tipos de miembro, tus nombres de reuniones, tus países, tus estados civiles — viven en la base de datos. Para que esas etiquetas sigan el idioma elegido por el usuario, cada tabla de referencia tiene una columna translations JSONB.
Este artículo cubre qué hay en esa columna, cuándo deberías completarla y cómo el renderizado recurre a un respaldo cuando falta una traducción.
La forma de translations
Cada fila de tabla de referencia tiene una columna JSONB llamada translations con esta forma:
{
"en": { "name": "Visitor" },
"es": { "name": "Visitante" },
"fr": { "name": "Visiteur" },
"pt": { "name": "Visitante" }
}Las claves de nivel superior son códigos de configuración regional (en, es, fr, pt). El valor de cada uno es un objeto de nombre de campo → cadena traducida. La mayoría de las filas de referencia solo tienen un campo name hoy, pero la misma columna se extiende limpiamente a otros campos localizables (descripción, forma plural) sin una migración.
Los códigos de configuración regional coinciden con la constante SUPPORTED_LOCALES en src/shared/lib/i18n-localize.ts:
| Código | Idioma |
|---|---|
en | English |
es | Español |
fr | Français |
pt | Português |
Cómo funciona la resolución
Cuando la interfaz necesita renderizar el nombre de una fila, llama al ayudante localize() con las traducciones de la fila, la columna heredada name como respaldo y la configuración regional activa del usuario:
localize(row.translations, row.name, language, "name")El ayudante recorre cuatro pasos de resolución en orden:
translations[locale][field]— coincidencia exacta en la configuración regional solicitada.translations.en[field]— respaldo en inglés.row[field]— la columna canónica heredada. (Para los tipos de miembro, eso esmember_types.name.)- Cadena vacía — el llamador puede renderizar un marcador de posición.
Entonces un usuario español viendo un tipo de miembro sin traducción al español ve la etiqueta en inglés en lugar de una celda en blanco. Un usuario viendo una reunión en portugués — una configuración regional menos traducida — ve portugués si está disponible, luego inglés, luego la columna name cruda. Ninguna configuración regional muestra silenciosamente una celda vacía.
Cuándo deberías completar las traducciones
El costo de UX de dejar las traducciones en blanco es pequeño (respaldo a inglés) pero visible para tus feligreses bilingües. Tres reglas generales:
Siempre traduce si tu congregación es bilingüe
Si predicas regularmente en dos idiomas o tienes miembros que solo leen uno, completa ambas etiquetas cada vez que agregues una fila de referencia. Los 20 segundos que toma cuando agregas un tipo de miembro evitan una etiqueta torpe solo en inglés en el perfil de un miembro español.
Traduce también las listas gestionadas por la plataforma
Países, estados, ciudades, géneros, estados civiles — estos vienen pretraducidos por la plataforma pero la cobertura no es del 100%. Si notas un país o estado mostrándose en inglés en tu interfaz en español, puedes marcarlo a través de soporte y el administrador de la plataforma completará la configuración regional faltante.
Omite las traducciones si eres monolingüe
Si toda tu congregación habla un idioma y no tienes planes de agregar otro, omite la entrada de traducciones. La cadena de respaldo asegura que el nombre canónico se renderice correctamente. Siempre puedes volver y completarlas más tarde — agregar una traducción nunca mueve la fila, solo agrega al JSONB.
La interfaz de entrada de traducciones
Cuando agregas o editas una fila de referencia, el diálogo muestra una entrada de Traducciones.
Parece una entrada de texto con pestañas — una pestaña por configuración regional soportada, por defecto en inglés. Escribe la etiqueta en inglés primero (que se refleja en la columna canónica name), luego cambia a las pestañas de español / francés / portugués para completar el resto.
Las pestañas que ves dependen de SUPPORTED_LOCALES. Agregar un nuevo idioma de plataforma es un cambio de una línea en i18n-localize.ts más el envío del archivo de traducciones de interfaz correspondiente — sin migración de base de datos. Las filas existentes simplemente tienen entradas vacías para la nueva configuración regional hasta que las completes.
Traducción masiva
Para administradores de la organización configurando un inquilino nuevo en español, el camino más rápido es:
- Agrega cada tipo de miembro en inglés primero.
- Abre la base de datos a través del módulo de Registros de Datos o tu proyecto de Supabase.
- Usa un solo UPDATE:
UPDATE member_types SET translations = jsonb_set(translations, '{es,name}', '"<nombre en español>"') WHERE name = '<nombre en inglés>'. - Actualiza la interfaz — cada miembro ya asignado a ese tipo ahora muestra la etiqueta en español.
Los administradores de la plataforma pueden hacer esto para las tablas de referencia globales (géneros, estados, geografía) bajo petición.
Qué se traduce dónde
| Tabla | Campo | Quién lo completa |
|---|---|---|
member_types | name | Admin org |
meetings | name | Admin org |
genders | name | Admin de plataforma |
relationship_statuses | name | Admin de plataforma |
countries | name | Admin de plataforma |
states | name | Admin de plataforma |
cities | name | Admin de plataforma |
pages (constructor de sitios) | title, body | Admin org (UI separada) |
notifications | subject, body | Admin org (UI separada) |
events | title, description | Admin org (editor de eventos) |
El patrón es consistente en toda la plataforma: en cualquier lugar donde los datos ingresados por el usuario necesiten seguir el idioma del visualizador, la fila obtiene una columna translations JSONB y la interfaz la lee a través del mismo ayudante localize().
Historia de migración
La columna translations se agregó en toda la plataforma en la migración 20260518020000_translations_jsonb_system junto con el ayudante localize(). Antes de eso, las tablas individuales tenían columnas _es (p. ej. meetings.name_es) que eran inconsistentes y no se extendían a nuevos idiomas. Esas columnas _es se han migrado en reuniones, meses, eventos, páginas y notificaciones — consulta los documentos del código base para la referencia canónica.
Si encuentras una columna _es antigua en src/integrations/supabase/types.ts, es un remanente en el archivo de tipos autogenerado en lugar de algo en lo que deberías escribir. Siempre escribe a través de la columna translations JSONB.
¿Qué pasa si necesito un quinto idioma?
Agrega el código de configuración regional a SUPPORTED_LOCALES en src/shared/lib/i18n-localize.ts, envía un archivo src/i18n/locales/<code>.json correspondiente con las cadenas de la interfaz, y la base de datos está lista sin una migración. Las filas existentes obtienen una entrada vacía para la nueva configuración regional; los administradores las completan con el tiempo. Envía un correo al equipo de ingeniería si tu inquilino necesita un idioma que no está en la lista soportada.
Siguiente
- Personalizar tipos de miembro — practica el flujo de trabajo en una lista que controlas completamente.
- Géneros y estados civiles — donde las traducciones son gestionadas por la plataforma.
- Países, estados, ciudades — pretraducidos con cobertura variable.