Con el Markdown → JSONL Converter se incrementó la recolección de documentos oficiales JSONL de 1 180 a 1 230.
Se constató que la canalización de traducción multilingüe se retrasa más de lo esperado, por lo que la estabilización podría requerir tiempo adicional.
Se probó la sincronización de documentos multilingües en un repositorio privado y, durante ese proceso, se establecieron los siguientes criterios.
Criterios de estructura de documentos
El documento en coreano se toma como documento base.
Los documentos en otros idiomas se ubican bajo la forma docs/<lang>/....
Las rutas que antes estaban directamente bajo docs/ se consideran documentos base en coreano y se trasladan a docs/ko/....
Los códigos de idioma deben ser estándares (p. ej., ja, zh, pt-BR) y no códigos arbitrarios como jp o ch.
El README.md en la raíz se mantiene como documento raíz.
Las traducciones del README también se tratan como documentos raíz.
Evitar que una modificación del README.md se propague erróneamente a archivos dentro de docs/.
Evitar que carpetas de idioma ya existentes como docs/en, docs/ja se aniden (p. ej., docs/ko/en).
En pruebas con archivos comprimidos, solo se extraen y aplican cambios a README y docs.
Criterios de enlaces y rutas
Los enlaces internos de README y de los documentos en docs se adaptan al idioma de destino. Por ejemplo, el enlace docs/ko/... del README coreano se cambia a docs/en/... en el README en inglés.
Las rutas relativas entre documentos dentro de docs también se ajustan según el idioma de destino.
Se asegura que las rutas de imágenes, enlaces a subdirectorios y rutas relativas no se rompan durante la traducción/sincronización.
Los enlaces de idioma en el README deben presentarse de forma que el usuario perciba que está cambiando o navegando al documento en ese idioma.
Criterios de sincronización automática
Cuando se agrega un archivo en docs/ko, se crea el archivo correspondiente en los demás idiomas.
Cuando se elimina un archivo en docs/ko, se elimina también en los demás idiomas.
Cuando se modifica un archivo específico en docs/ko, solo los archivos correspondientes en los demás idiomas se marcan para regeneración.
No se traduce todo el conjunto desde cero en cada ejecución.
Los archivos/idiomas que ya se tradujeron con éxito no se vuelven a traducir.
Si ocurre un error, los resultados exitosos no se eliminan.
Sólo se elimina el archivo que falló y, en la siguiente ejecución, se vuelve a generar ese archivo.
Se omiten carpetas de idioma que ya coinciden mediante comparación de número de archivos o archivos de versión simples.
Los archivos de versión utilizan formas simples como v1 o un número, en lugar de JSON/ hashes complejos.
Criterios de procesamiento de traducción
Las traducciones se prueban con la API real.
No se utilizan simulaciones de éxito (mock).
Se determina el tamaño de los fragmentos (chunks) según los límites oficiales de contexto/salida del modelo.
Se prioriza truncar la salida para que no supere max_tokens más que el contexto de entrada.
Cada fragmento se verifica inmediatamente después de traducirse.
Las áreas que fallan en la verificación se colocan en una cola.
Sólo los fragmentos en la cola se vuelven a dividir (a mayor profundidad) y se re‑traducen/re‑verifican.
Se evita la estrategia de verificar todo al final después de concatenar todos los fragmentos.
Criterios de verificación
Confirmar que no quede texto en coreano en el resultado traducido.
Verificar que no se hayan eliminado espacios.
Asegurarse de que la estructura Markdown se conserve.
Comprobar que los bloques de código, enlaces, imágenes y encabezados permanezcan intactos.
Para idiomas como el chino, que tienden a reducir la longitud, no se juzga solo por la diferencia de longitud.
Revisar manualmente el producto final para detectar cualquier anomalía respecto al original.
Criterios de registro de fallos
Diferenciar causas de fallos como HTTP 429, 504, RemoteDisconnected, finish_reason=length, respuestas vacías, etc.
Registrar en los logs: encabezados de respuesta, cuerpo de respuesta, tiempo de ejecución, nombre del modelo, tamaño de entrada y consumo de tokens.
Garantizar que un solo fallo no detenga toda la canalización ni haga desaparecer los productos generados.
Si los fallos se repiten, analizar primero la causa raíz.
Criterios de uso de la API de NVIDIA
La canalización de traducción se prueba con la API de NVIDIA.
gpt-oss-120b permite un contexto de entrada de hasta 128 k tokens, pero la política de NVIDIA limita la salida a aproximadamente 4 096 tokens.
Aunque se pueda enviar una gran entrada, la salida puede truncarse; por ello, el tamaño de los fragmentos se define según el límite de salida de 4 096 tokens.
Se intentan hasta 40 llamadas por minuto; si ocurre un error, se aplican políticas de espera y reintento.
Criterios de codificación rígida (hard‑coding)
Se utilizan reglas estructurales como docs/<lang>, marcadores, expresiones regulares de enlaces y análisis de bloques de código.
No se sustituyen ni eliminan palabras arbitrariamente.
No se elimina example.com de forma arbitraria.
No se registra cada archivo de documento individualmente mediante su ruta.
No se forzan sustituciones de expresiones o palabras específicas.
Criterios operacionales
Se revisan tanto GitHub Actions como el runner auto‑alojado en Mac.
En Mac, el flujo incluye commit y push automáticos al finalizar.
Se provee una vista del progreso similar a la de GitHub Actions.
Los logs deben indicar qué idioma/archivo/fragmento está en proceso.
Se registran claramente el nombre de la rama, la URL de ejecución, la causa del fallo y el progreso actual.
Con curl es posible obtener respuestas de texto e incluso generar imágenes sin necesidad de una clave API, lo que permite experimentar sin preocuparse por facturación.
Se desarrolló un prototipo divertido con ello y, tras usarlo más, se planea publicar el proyecto más adelante.
Actualizaciones de Qwen Validation Debugger
Se reorganizó la estructura de ranuras JSONL para la separación de versiones:
docs_chunks se mantiene como evidencia de explicación de código, conservando slots separados para código Godot 3 y Godot 4.
En lugar de crear JSONL independientes para api_mapping y label_prototypes de Godot 3 y Godot 4, se combinan ambos códigos en un solo JSONL que sirve como evidencia de conversión 3 → 4.
El valor esperado de validación para la conversión 3 → 4 es sí para código Godot 3 y no para código Godot 4.
Para la conversión sin relación, el valor esperado es no tanto para Godot 3 como para Godot 4.