Has publicado nuevas traducciones pero tu aplicación sigue mostrando las antiguas. Esto casi siempre es un problema de caché — aquí te explicamos cómo diagnosticarlo y resolverlo.
Entender las capas de caché
Cuando publicas, las traducciones pasan por varias capas de caché antes de llegar al usuario:
Tú publicas
→ CDN origin actualizado (inmediato)
→ CDN edge cache purgado (inmediato)
→ Caché en memoria del SDK expira (hasta 60s)
→ Caché del navegador/framework expira (hasta 60s)
→ El usuario ve las nuevas traducciones
El retraso máximo desde la publicación al usuario es de aproximadamente 60 segundos en la mayoría de configuraciones.
Correcciones rápidas
1. Esperar 60 segundos y forzar recarga
La solución más sencilla: espera un minuto y luego pulsa Cmd+Shift+R (Mac) o Ctrl+Shift+R (Windows) para ignorar el caché del navegador.
2. Verificar que el CDN tiene datos frescos
curl -I https://cdn.better-i18n.com/your-org/your-project/en/translations.json
Comprueba la cabecera Age — si es 0 o muy baja, el CDN tiene datos frescos. La cabecera x-cache-status muestra HIT o MISS.
3. Limpiar caché del SDK (desarrollo)
Si estás en desarrollo y necesitas ver los cambios inmediatamente, el TtlCache del SDK se puede evitar reiniciando tu servidor de desarrollo.
Comportamiento específico por framework
Next.js (ISR)
Next.js ISR añade su propia capa de caché. Con el messagesRevalidateSeconds: 30 predeterminado, Next.js puede tardar hasta 30 segundos en re-fetch desde el CDN.
Para forzar actualización inmediata en desarrollo:
- Reinicia el servidor de desarrollo, o
- Añade
?_vercel_no_cache=1para evitar el caché ISR
En producción: ISR funciona con stale-while-revalidate. La primera solicitud después de 30 segundos activa una revalidación en segundo plano. La siguiente solicitud obtiene datos frescos.
React SPA / TanStack
El TtlCache del SDK tiene un TTL de 60 segundos. Después de 60 segundos, el siguiente ciclo de renderizado obtiene traducciones frescas.
Expo / React Native
Las aplicaciones móviles también usan el TTL de 60s. Forzar el cierre y reabrir la app activa un fetch fresco. Si tienes habilitado el almacenamiento persistente, el SDK escribe datos frescos en el almacenamiento en cada fetch CDN exitoso.
Remix / Hydrogen
El fetch basado en loaders significa que cada solicitud al servidor puede obtener datos frescos. El TtlCache del SDK es la capa de caché principal (60s).
Verificación del purge
Al publicar, la plataforma purga automáticamente el caché del CDN. Si sospechas que el purge no funcionó (raro), puedes verificar:
- Obtén las traducciones directamente del CDN
- Comprueba el cuerpo de la respuesta para tus nuevos valores de traducción
- Si están obsoletos, espera 60 segundos (el
max-age: 60del CDN expirará naturalmente)
Nota: El CDN está diseñado para siempre devolver HTTP 200, incluso durante errores. Si ves
{}o{ "fallback": true }, significa que las traducciones aún no han sido publicadas (no es un problema de caché).
Cuándo preocuparse
Si las traducciones siguen obsoletas después de 5 minutos:
- Revisa el panel de control — ¿se completó realmente la publicación?
- Verifica la URL del CDN directamente con
curl - Comprueba que tu ID de proyecto coincide exactamente (distingue mayúsculas y minúsculas)
- Ejecuta
better-i18n doctorpara información de diagnóstico