10 de julio de 2026 | idea_world

Se avanzó la recolección de documentos oficiales JSONL con el Convertidor Markdown → JSONL, pasando de 1180 a 1230 archivos.
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 tardar bastante.
Se probó la canalización de sincronización de documentos multilingües en un repositorio privado, y los criterios establecidos fueron los siguientes.

Criterios de estructura de documentos:

Se toma el documento en coreano como documento base.
Los documentos multilingües se ubican en la forma docs/<lang>/....
Las rutas que estaban directamente bajo docs/ se consideran documentos base en coreano y se trasladan a docs/ko/....
Los códigos de idioma no son códigos arbitrarios como jp, ch, sino códigos estándar como ja, zh, pt-BR.
El README.md raíz se mantiene como documento raíz.
Las traducciones del README también se tratan como base raíz.
Se evita que la modificación del README.md se propague incorrectamente como una modificación de archivos dentro de docs/.
Se evita que carpetas de idioma existentes como docs/en, docs/ja se aniden como docs/ko/en.
En pruebas con archivos comprimidos, solo se extraen y reflejan README y docs.

Criterios de enlaces y rutas:

Los enlaces internos del README y de docs se cambian según el idioma de destino. Por ejemplo, el enlace docs/ko/... del README en coreano se convierte en docs/en/... en el README en inglés.
Las rutas relativas entre documentos internos de docs también se ajustan al 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 del README se presentan de forma que el usuario perciba que está navegando o cambiando 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 el archivo correspondiente en los demás idiomas.
Cuando se modifica un archivo específico en docs/ko, solo se vuelve a generar el archivo correspondiente en los demás idiomas.
No se traduce todo desde cero cada vez.
Los archivos/idiomas que ya se tradujeron con éxito no se vuelven a traducir.
No se eliminan los resultados exitosos aunque haya fallos.
Solo se elimina el archivo que falló y, en la siguiente ejecución, se vuelve a generar ese archivo.
Se omiten las 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 usan un formato sencillo como v1 o un número, en lugar de JSON/ hash complejos.

Criterios de procesamiento de traducción:

La traducción se prueba con la API real.
No se utilizan simulaciones de éxito.
Se determina el tamaño de los fragmentos (chunks) según los límites oficiales de contexto/salida del modelo.
Se prioriza cortar la salida de traducción para que no supere max_tokens respecto al contexto de entrada.
Se verifica cada fragmento inmediatamente después de traducirlo.
Las áreas que fallan en la verificación inmediata se colocan en una cola.
Sólo los fragmentos fallidos en la cola se vuelven a dividir con mayor profundidad y se re‑traducen/re‑verifican.
Se evita una arquitectura que solo verifica una vez al final después de combinar todos los fragmentos.

Criterios de verificación:

Se comprueba que no queden fragmentos en coreano en el resultado traducido.
Se verifica que no se hayan eliminado espacios.
Se asegura que la estructura Markdown se mantenga.
Se verifica que los fences de código, enlaces, imágenes y encabezados se conserven.
Para idiomas como el chino, cuya longitud disminuye, no se juzga solo por la comparación de longitud.
Se revisa el producto final leyendo el texto para confirmar que no haya anomalías respecto al original.

Criterios de registro de fallos:

Se distinguen causas de fallos como HTTP 429, 504, RemoteDisconnected, finish_reason=length, respuestas vacías, etc.
Se registran en el log los encabezados de respuesta, cuerpo de respuesta, tiempo de ejecución, nombre del modelo, tamaño de entrada y uso de tokens.
Un solo fallo no debe detener toda la canalización ni hacer desaparecer los resultados.
Si los fallos se repiten, primero se analiza la causa.

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, pero la política de la API de NVIDIA limita la salida a aproximadamente 4096 tokens.
Aunque se pueda proporcionar una gran entrada, la salida puede truncarse por el límite, por lo que el criterio de fragmentado real se basa en el límite de salida de 4096 tokens.
Se intentan hasta 40 llamadas por minuto; si ocurre un error, se aplica una política de espera/reintento.

Criterios de codificación rígida:

Se utilizan reglas estructurales como docs/<lang>, marcadores, expresiones regulares de enlaces y análisis de fences de código.
No se cambian ni eliminan palabras arbitrariamente.
No se elimina example.com arbitrariamente.
No se registra cada archivo de documento individualmente mediante su ruta.
No se sustituyen forzadamente expresiones o palabras específicas por otras.

Criterios operacionales:

Se revisan tanto GitHub Actions como el runner auto‑alojado en Mac.
En Mac, el flujo incluye commit/push automático al finalizar.
Se permite visualizar el progreso como en GitHub Actions.
Se pueden consultar en los logs 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.

Separado de la traducción, recientemente descubrí un documento interesante.

Se revisó Pollinations APIDOCS.md
Con curl se puede obtener una respuesta de texto sin necesidad de una clave API, y parece posible generar imágenes también
Creo que podríamos experimentar fácilmente sin preocuparnos por crear una clave API ni por facturación
Primero jugué con esto y, después de usarlo un poco más, pienso publicarlo más adelante
Se reorganizó la estructura de ranuras JSONL de separación de versiones del Qwen Validation Debugger
- docs_chunks se mantiene como evidencia de explicación de código, conservando ranuras para código Godot 3, código Godot 4 y explicaciones no relacionadas
- En lugar de crear JSONL separados 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
- Los valores esperados de validación del JSONL de conversión 3 → 4 son Sí para código Godot 3 y No para código Godot 4
- Los valores esperados de validación del JSONL de conversión no relacionada son No tanto para código Godot 3 como para Godot 4
Retrospectiva: docs/retrospectives/2026-07-10.md