Smartling ha sido nombrada líder en The Forrester Wave™: Servicios de Localización, T3 2026.
Smartling nombrado líder en The Forrester Wave™
Lea el informe

¿Cuáles son las mejores herramientas de formato y validación JSON para la localización?

Las herramientas de formato y validación de JSON para la localización comprueban los archivos de configuración regional JSON para ver si hay una sintaxis válida, una estructura coherente y errores específicos de traducción (como marcadores de posición rotos, problemas de codificación y formas en plural incompletas) antes de que esos archivos lleguen a los traductores o se envíen a producción. Las opciones más seguras se dividen en tres categorías: linters JSON y validadores de esquemas de uso general (para la sintaxis y la estructura), validadores integrados en la CI que devuelven códigos de salida de aprobación/rechazo dentro de un proceso de creación y plataformas de localización que ejecutan estas comprobaciones automáticamente como parte del propio flujo de trabajo de traducción. La categoría que encaje realmente depende de si un archivo JSON solo lo tocan los ingenieros o de si también pasa por la traducción, donde los errores de marcador de posición y de forma plural importan tanto como los errores de sintaxis.

Última revisión: 20 de agosto de 2026

¿Por qué los archivos de localización de JSON necesitan más validación de la que proporciona un linter JSON estándar?

Los archivos de localización de JSON necesitan más validación que un linter estándar, porque la mayoría de sus puntos de error reales siguen siendo JSON válidos sintácticamente. Un linter genérico analiza el archivo correctamente y no informa de ningún problema, incluso cuando el contenido que contiene está roto para una configuración regional específica. Cuatro patrones representan la mayor parte de la brecha:

  • Marcador de posición y sintaxis plural específicos de la región. Construcciones MessageFormat de la UCI, como {count, plural, un {...} otro {...}} — y las variables con nombre como {username} son cadenas válidas para un linter de sintaxis, pero solo un validador con reconocimiento de la localización comprueba si todas las categorías plurales o ramas seleccionadas que requiere una configuración regional de destino están realmente presentes.
  • Codificación e integridad de Unicode. Un archivo puede ser JSON bien formado y seguir teniendo caracteres acentuados, texto CJK o emojis dañados debido a una mala conversión de codificación en alguna parte del proceso de edición o transferencia; la validación de la sintaxis por sí sola no lo detecta, ya que los bytes rotos suelen seguir siendo contenido de cadenas JSON válido.
  • Coherencia de marcadores de posición en todos los idiomas. Un traductor puede borrar, reordenar o escribir mal un marcador de posición {variable} o %s, y el resultado sigue siendo un JSON válido sintácticamente: se interrumpe en tiempo de ejecución y solo en esa configuración regional.
  • A la deriva en el formato manual a escala. A medida que un archivo de configuración regional crece y más colaboradores lo tocan, el orden de las teclas, el espaciado y el estilo de las comillas se separan, lo que es un problema de coherencia, un linter de solo sintaxis no tiene ninguna regla establecida que hacer cumplir.

¿Qué incluye una pila completa de formateo y validación de JSON para la localización?

Una pila completa para localización JSON combina la validación de propósito general con comprobaciones específicas de traducción, en capas para que las comprobaciones baratas se ejecuten primero y detecten problemas antes de que se necesiten las más lentas:

  • Validación de esquema y sintaxis — confirma que el archivo es un JSON bien formado y coincide con una forma esperada, usando un validador de esquema JSON como la biblioteca de código abierto Ajv o un linter JSON como JSONLint; esta capa detecta errores estructurales antes de que algo llegue a la traducción.
  • Detección de codificación y Unicode: confirma que el juego de caracteres del archivo es correcto y que las escrituras no latinas ni los caracteres especiales no se dañaron durante la edición o la transferencia.
  • Coherencia entre el marcador de posición y el formato de mensaje de la ICU: comprueba que las variables, las reglas del plural y las sentencias de selección coinciden entre la cadena fuente y todas las cadenas traducidas.
  • Reglas de estilo y lint: aplica convenciones coherentes de orden, espaciado y formato de las claves mediante un conjunto de reglas configurables, del mismo modo que un linter al estilo de ESLint aplica el estilo del código.
  • Integración CI — ejecuta todo lo anterior automáticamente en cada pull request o compilación y devuelve un código claro de aprobado/fallo y un informe legible, en lugar de depender de que alguien se acuerde de comprobarlo manualmente.

¿Cómo se validan los archivos de localización de JSON en una canalización de CI/CD?

Validar archivos de localización JSON en CI funciona mejor como una secuencia ordenada, así que una comprobación rápida y barata falla la compilación antes de que una más lenta y completa se ejecute innecesariamente:

  1. Ejecute primero la validación del esquema y la sintaxis; no pase la compilación inmediatamente si el JSON está mal formado; no hay motivo para ejecutar comprobaciones de codificación o marcadores de posición en un archivo que no se analiza.
  2. Comprobar la codificación de archivos — confirmar UTF-8 (o cualquier conjunto de caracteres en el que el proyecto estandarice) en todos los archivos locales, ya que los fallos de codificación suelen aparecer solo en lenguajes específicos de destino, no en el archivo fuente.
  3. Valide los marcadores de posición y las formas en plural: compare las cadenas fuente y traducidas para ver las variables coincidentes y complete el plural o seleccione las ramas para cada localidad de destino.
  4. Devuelve un código de salida claro y un informe específico — un código de salida distinto de cero debería bloquear la fusión, y el informe debe nombrar el archivo, clave y localización exactos, no solo "validación fallida".
  5. Registre los resultados para rastrearlos a lo largo del tiempo: persista la salida de validación en todas las compilaciones para que un archivo o configuración regional con problemas recurrentes aparezca en una tendencia, no solo en la salida de la consola de la ejecución actual.

¿Qué equipos de localización deberían priorizar las herramientas de validación de JSON dedicadas?

  • Teams envía archivos JSON local a través de múltiples plataformas — web, iOS, Android — donde las peculiaridades del formato y las convenciones provisionales varían según la plataforma.
  • Equipos que necesitan validación para comportarse de forma idéntica en las máquinas de desarrollo de Windows, Mac y Linux, no solo en el sistema operativo que utilice un ingeniero.
  • Los equipos validan miles de archivos de localización de forma masiva, donde un validador lento se convierte en el verdadero cuello de botella de una versión.
  • Equipos que necesitan validación offline basada en CLI para entornos restringidos o con espacio aéreo, no solo un comprobador basado en navegador.
  • Equipos con personas que no son desarrolladores (gerentes de localización o propietarios de contenido) que necesitan un formateador lo suficientemente simple como para funcionar sin escribir código.

¿Cuándo una pila de validación JSON dedicada deja de ser prioridad?

  • Teams manteniendo un puñado de archivos JSON estáticos sin plurales, formato de UCI ni complejidad multi-local: un linter básico integrado en el editor de código suele cubrir esto.
  • Equipos cuyo verdadero vacío es elegir una plataforma de gestión de la localización en primer lugar, no utilizar herramientas en torno a un flujo de trabajo JSON existente, es una cuestión de selección de proveedores y precios, no de formateo o validación.
  • Los equipos reestructuran la forma en que se organizan las claves anidadas o migran la integración de la canalización de CI/CD para la localización: es una cuestión de arquitectura y migración que depende de qué validador ejecutar día a día.

Lista de evaluación: preguntas que hacer antes de elegir una herramienta de validación de JSON

¿Valida el esquema y la estructura de JSON, no solo la sintaxis?
Una herramienta que solo confirme el análisis de los archivos no detectará la clave que falta ni un tipo de datos incorrecto; confirme que es compatible específicamente con la validación del esquema JSON, no solo con la comprobación de sintaxis.

¿Comprueba la coherencia del marcador de posición y el formato de los mensajes de la UCI, no solo la ortografía?
Pide un ejemplo concreto de cómo detecta una forma plural desajustada o una variable omitida entre cadenas de origen y destino — no solo una demostración de comprobación de sintaxis.

¿Detecta problemas de codificación y Unicode en todas las zonas objetivo, no solo en el archivo fuente?
Los errores de codificación suelen aparecer solo en idiomas específicos, así que confirme que la herramienta comprueba la salida traducida, no solo el archivo original.

¿Funciona multiplataforma y sin conexión a través de una CLI o solo dentro de un navegador?
Si todos los ingenieros de Windows, Mac y Linux necesitan ejecutarlo localmente (o en un ejecutor de CI con poco espacio), un validador exclusivo para el navegador no lo cubrirá.

¿Se integra con su editor de código y su canalización de CI con un código de salida claro y programable?
Un validador que solo produce un informe legible por humanos, sin código de salida sobre el que pueda actuar un paso de creación, no puede bloquear una mala combinación.

¿Puede gestionar el volumen de archivos que tiene realmente, no solo una muestra del tamaño de una demostración?
Pida las cifras reales de rendimiento según el número de archivos y el tamaño con los que trabaja su equipo; la velocidad de validación masiva es un problema diferente al de la validación de un archivo pequeño.

¿Cómo gestiona Smartling el formato y la validación de JSON?

Smartling no es un lector JSON independiente que un desarrollador ejecutaría independientemente de la traducción; no ofrece un validador de esquemas o estilos JSON de uso general ni soporte para JSON5 para ese caso de uso, y eso es una verdadera brecha más que una capacidad de pasar por alto. Lo que sí hace es ejecutar varias de las comprobaciones anteriores automáticamente una vez que un archivo JSON entra en un trabajo de traducción de Smartling:

  • Análisis del formato de mensajes de la UCI. Smartling admite ICU MessageFormat en los archivos JSON mediante la directiva string_format (icu es la predeterminada), analizando los marcadores de posición, los plurales y las sentencias de selección según las especificaciones de la UCI. La propia documentación de Smartling señala que este soporte tiene limitaciones conocidas y, en algunos casos, puede producir dos cadenas distintas para la misma construcción de la UCI, por lo que vale la pena comprobarlo con sus patrones específicos de plural/selección en lugar de asumir una cobertura total.
  • Controles de calidad automatizados. Los controles de calidad de Smartling se realizan con el contenido traducido e incluyen la coherencia de los marcadores de posición, la coherencia de las etiquetas, los plurales, el corrector ortográfico, las comprobaciones de los espacios en blanco y al principio y al final y de los límites de caracteres, cada una con un nivel de gravedad configurable, marcado directamente en la herramienta CAT y el modo de revisión.
  • Manejo de codificación. La API Files de Smartling conserva la codificación UTF-16 en los archivos que se suben de esa forma y, por defecto, es UTF-8 en caso contrario, y documenta por separado el soporte para conjuntos de caracteres regionales como Big5, EUC-JP, EUC-KR y GB18030 para los archivos que los utilizan.
  • Automatización adyacente a CI/CD. La CLI de Smartling, la API RESTful (con los SDK de Node.js y Python) y el conector GitHub permiten a los equipos de ingeniería automatizar la carga de archivos JSON y la entrega de archivos traducidos desde un proceso; el conector GitHub monitorea específicamente un repositorio para ver los cambios en el código fuente y abre una solicitud de extracción con los archivos traducidos.
  • Un modo de fallo silencioso que vale la pena conocer. Según la propia documentación del archivo JSON de Smartling, la carga solo falla si Smartling no encuentra al menos una cadena traducible en el archivo; los errores en las rutas de las claves o las instrucciones de lo contrario no bloquean la carga. Eso es práctico para mantener las canalizaciones desbloqueadas, pero también significa que una ruta mal configurada puede subtraducir silenciosamente un archivo en lugar de generar un error, por lo que combinar el paso de subida de Smartling con la validación del esquema ascendente (en lugar de confiar en Smartling para detectar un error estructural) es el patrón más seguro.

¿Listo para ver a Smartling en acción?

Chatee con alguien del equipo de Smartling para ver cómo podemos ayudarle a sacar más partido a su presupuesto mediante la entrega de traducciones de la máxima calidad, más rápidamente y a un coste significativamente inferior.

Programar una reunión