title: "Cómo se produce una traducción",

summary:

"Qué ocurre entre enviar un requisito informal y recibir una especificación formal: los ajustes que la moldean, qué modelo la ejecuta y qué queda guardado.",

category: "core-translation-engine",

tags: [

"translation-pipeline",

"model-selection",

"bring-your-own-key",

"history",

],

lastReviewed: "2026-09-10",

};

Cómo se produce una traducción

Cuando envías un requisito, DevSpeak lo convierte en un documento formal dirigido a una audiencia concreta. Esta página explica qué ocurre en medio: lo suficiente para anticipar el comportamiento y resolver problemas, sin necesidad de saber cómo está construido.

Qué cubre esta página

  • Qué ajustes tuyos cambian el resultado, y de qué manera.
  • Qué modelo ejecuta tu traducción y cómo controlar esa elección.
  • Qué queda guardado después y para qué sirve.
  • Qué moldea el resultado

    Cinco entradas determinan el documento que recibes. Todo lo demás es fijo.

    1. Tu texto: el requisito informal, la nota o el borrador que envías.

    2. Formato de salida: especificación técnica, tickets de Jira, diseño de API, RFC, modelo de datos o prompt.

    3. Audiencia: desarrollador junior, desarrollador senior, tech lead, SRE o ingeniero de datos. Es el ajuste que más cambia el resultado: el mismo requisito escrito para un SRE empieza por los modos de fallo, y para un desarrollador junior empieza por pasos ordenados.

    4. Contexto técnico: backend, frontend, móvil, datos/ML o DevOps.

    5. Tono: un control deslizante de conciso a detallado. Por debajo del punto medio obtienes una reescritura ajustada; por encima, un documento completo con secciones y encabezados. El cambio en el punto medio es deliberado y se nota, así que si la extensión no es la que esperabas, revisa esto primero.

    En los planes de pago, las instrucciones personalizadas se añaden como restricciones permanentes: terminología propia, reglas de formato o elementos que deben aparecer siempre.

    Qué modelo la ejecuta

    De forma predeterminada, el selector de modelo está en Auto y DevSpeak elige el modelo para cada solicitud: las entradas largas o con imágenes se enrutan a la opción más capaz, y todo lo demás permanece en la ruta rápida predeterminada. No tienes que configurar nada, y DevSpeak se ocupa de la disponibilidad por ti: si el modelo que atiende tu solicitud no está disponible, otro toma el relevo en lugar de fallar la solicitud.

    Puedes anular esto de dos maneras:

  • Elegir un modelo en el selector del editor de traducción para usarlo en la siguiente generación. Es útil para reproducibilidad y para comparar cómo dos modelos tratan el mismo requisito.
  • Conectar la clave de tu propio proveedor en Settings → Keys & Providers. Las traducciones pasarán entonces por tu cuenta con ese proveedor.
  • Cuando aplica más de uno, el orden es: primero la elección explícita de modelo, luego tu propio proveedor y después Auto. Seleccionar un modelo de la lista siempre usa ese modelo, aunque tengas una clave conectada; así que cuando quieras tu propio proveedor, selecciónalo explícitamente en esa misma lista.

    Qué ocurre con tu contenido

    Las traducciones de texto se guardan en tu historial con la entrada, la salida y los ajustes utilizados, para que puedas reabrirlas, exportarlas o refinarlas más tarde.

    Los adjuntos se suben antes de ejecutar la traducción y quedan vinculados al registro. Al reabrir una traducción antigua, sus archivos siguen accesibles.

    Los documentos grandes se procesan como un trabajo en segundo plano en lugar de una sola solicitud. Puedes salir de la página y volver: el trabajo continúa y se informa del progreso mientras se ejecuta.

    Páginas relacionadas

  • [El flujo de traducción por defecto](/docs/module-3-core-translation-engine/chapter-1-architecture/2-default-translation-flow)
  • [Expectativas de latencia](/docs/module-3-core-translation-engine/chapter-1-architecture/4-latency-expectations)