Skip to content
better-i18n.com

Publicar es el paso que hace real una traducción para tu aplicación. Hasta que publicas, todo lo que has escrito vive solo en el panel.

No hay ningún build ni despliegue de por medio.

Qué ocurre #

Code
Publish
  → las traducciones se escriben en el origen del CDN
  → se purga la caché de lo que ha cambiado
  → tu aplicación descarga la nueva versión en su siguiente petición

Cómo hacerlo #

  1. Abre tu proyecto
  2. Pulsa Publish
  3. Lee lo que aparece en la lista: esta es la parte importante
  4. Confirma

La ventana enumera exactamente lo que va a salir en vivo, agrupado para que puedas verlo en vez de fiarte de un número.

Lee la lista antes de confirmar #

Los borradores también se publican. Esto sorprende, así que conviene decirlo sin rodeos: la acción de publicar incluye tanto las traducciones aprobadas como los borradores. El valor por defecto de la API es solo aprobadas; el panel amplía ese criterio a propósito para que lo que se enumera sea lo que realmente se envía — decir «12 listas» y publicar 9 sería peor.

La consecuencia: borrador no significa «no puede salir en vivo», sino «todavía nadie ha respondido por esto». Si necesitas que la aprobación sea una puerta real, revisa antes de publicar en lugar de confiar en que el estado lo retenga. Consulta ¿Cómo reviso y apruebo traducciones?.

Cuánto tardan en verlo los visitantes #

El CDN sirve las traducciones con una caché de un minuto, y publicar purga lo que ha cambiado, así que la respuesta habitual son segundos y un minuto es el techo.

Capas que pueden añadir su propio retraso:

CapaRetraso
Edge del CDNSe purga al publicar; si no, max-age=60
Caché en memoria del SDKHasta su intervalo de refresco
ISR de Next.jsEl revalidate que hayas configurado

Si tu aplicación renderiza las traducciones en tiempo de build o las cachea una hora, ese número es tuyo, no nuestro. He publicado pero mi aplicación sigue mostrando traducciones antiguas explica cómo encontrar la capa que las retiene.

Desde la CLI #

Bash
better-i18n publish:status   # qué saldría en vivo ahora mismo
better-i18n publish          # hacerlo

Ejecutar publish:status primero en un pipeline merece la pena: es la respuesta honesta a «¿hay algo pendiente?».

No hay reversión #

La publicación no está versionada y no existe una instantánea que restaurar. Arreglar una publicación mala consiste en editar la traducción y volver a publicar —cosa de un minuto, así que rara vez es una crisis—, pero significa que la revisión ocurre antes del botón, no después.

Cada publicación queda registrada como un job que puedes inspeccionar:

Bash
better-i18n syncs list
better-i18n syncs get <syncId>