La mayor parte de tu contenido puede publicarse en cuanto el motor lo devuelve. Pero no siempre. Una divulgación regulada, una instrucción médica, un titular que representa a la marca: en esos casos, quieres que una persona lea la traducción y dé el visto bueno antes de que se publique, no después de que un cliente presente una queja.
La forma habitual de meter a una persona en un flujo automatizado suele ser la más dolorosa: dejar la solicitud abierta mientras alguien revisa, montar tu propia cola de revisión o conectar a mano la API de un proveedor de traducción. Esta etapa lo resuelve dentro del propio trabajo. Cuando humanEdit está activado, el trabajo asíncrono ejecuta el motor y luego se pausa para que intervenga una persona —tu equipo o un profesional externo— y se reanuda con su edición, trasladando ese resultado a cualquier etapa posterior.
Es la tercera etapa de la canalización de localización y, como todas las etapas, solo se aplica a los trabajos creados mediante la API de localización asíncrona. ¿Aún no conoces la canalización? Empieza por la Descripción general.
En esta página
Cómo funciona la pausa#
Después del paso principal de traducción, el trabajo entrega la traducción generada por IA a una persona para su revisión. Esa persona la lee y, después, o bien la aprueba tal cual o bien envía una versión editada. Solo entonces continúa el trabajo. El resultado humano —aprobado o editado— se convierte en la entrada de cada etapa posterior y, en última instancia, en el outputData del trabajo.
La objeción evidente a pausar un trabajo durante minutos, horas o incluso un día es el coste: una solicitud abierta sigue consumiendo recursos aunque no esté pasando nada. Esta etapa no funciona así.
La espera se basa en eventos, no en mantener una conexión abierta
El flujo de trabajo se reanuda a partir de un evento: un revisor que envía su revisión desde el panel (Revisión interna) o una devolución de llamada del proveedor de traducción (Revisión externa). No hace sondeo en un bucle continuo ni mantiene una conexión abierta, así que un tiempo de espera largo no consume recursos en segundo plano. Un trabajo puede esperar 48 horas a una persona igual que espera a un modelo: está aparcado, no dando vueltas.
Hay dos modos de revisión disponibles, que se eligen por motor. Solo cambia quién hace la lectura: la pausa, la reanudación y el comportamiento posterior son idénticos.
Revisión interna#
Tu equipo revisa las traducciones directamente en el panel de Lingo.dev. Las revisiones pendientes llegan a la página Human Reviewer de tu organización (/orgs/<org-id>/human-reviewer), y se notifica a los revisores cuando entran nuevos elementos. Un revisor reclama un elemento y luego aprueba la traducción tal cual o envía una versión editada. El trabajo se reanuda de inmediato con ese resultado.
Un segundo revisor no puede hacerse cargo de un elemento en el que otra persona ya esté trabajando. Las reclamaciones son exclusivas: solo un revisor puede tener un elemento a la vez, así que dos personas nunca editan la misma traducción ni se pisan sin darse cuenta. La cadena queda bloqueada para quien la haya reclamado hasta que la libere o la envíe.
La Revisión interna es el modo predeterminado para los motores nuevos. Recurre a ella cuando tu equipo tiene la experiencia lingüística dentro de casa y quieres un control total sobre la redacción final, sin terceros de por medio.
Permisos#
La revisión interna no está abierta a todo el mundo dentro de la organización: la página Human Reviewer está protegida por permisos, así que una traducción en revisión solo es visible para las personas a las que concedas acceso. Un administrador de la organización asigna ese acceso mediante roles (Ajustes → Roles):
| Permiso | Qué permite |
|---|---|
Revisar traducciones (engine:review_translations) | Ver y gestionar la cola de revisión: reclamar una traducción pendiente, editarla, aprobarla tal cual o enviar la versión editada |
Gestionar revisiones (org:manage_reviews) | Historial de revisión y estadísticas de revisores de todas las revisiones internas de la organización |
Los dos permisos están separados a propósito. Un revisor solo necesita Revisar traducciones: con ese único permiso puede hacer todo el trabajo, de principio a fin: reclamar, editar, aprobar y enviar. Gestionar revisiones es para quien supervisa la operación; añade la vista de historial y estadísticas de toda la organización, pero por sí solo no da acceso a la cola. Concede ambos a una persona responsable que revisa e informa; concede solo el primero a alguien que únicamente trabaja la cola.
Revisión externa#
Cuando no tienes revisores internos para un idioma, la traducción se envía en su lugar a un traductor profesional cualificado a través de un proveedor externo. El trabajo se pausa exactamente igual; se reanuda cuando el proveedor devuelve la traducción editada. En tu código no cambia nada: la diferencia está en quién lee la cadena, no en cómo se comporta el trabajo.
La Revisión externa tiene dos niveles, y la diferencia responde a la precisión que exige el contenido:
| Nivel | Ideal para |
|---|---|
| Standard | Traducción precisa con voz humana: copy de marketing, cadenas de interfaz y contenido de ayuda |
| Pro | Uso profesional con un listón de precisión aún más alto: contenido legal, médico y regulado |
Conviene dejar esto claro: en la Revisión externa hay un traductor humano real al otro lado, con los plazos y el coste que eso implica. No es un modelo más rápido. Úsala cuando lo importante sea precisamente el criterio de una persona —texto regulado, contenido de alto riesgo— y apóyate en la vía solo de IA para la mayor parte del contenido que no lo necesite.
Tiempo de espera#
Una etapa humana introduce un riesgo que las etapas de IA no tienen: que la persona nunca responda. El revisor está de vacaciones, el proveedor va con retraso, el elemento se olvida. Si no hubiese límite, el trabajo esperaría para siempre.
Por eso la espera está acotada. Tú defines cuánto tiempo espera el flujo de trabajo al resultado humano: el mismo ajuste timeoutHours se aplica a ambos modos de revisión. Si el tiempo de espera vence sin respuesta, la etapa se marca como skipped y el trabajo continúa con la traducción de IA como resultado final. El valor predeterminado es 48 horas.
Conviene decirlo sin rodeos: si se agota el tiempo, acabarás publicando la traducción de IA sin revisar. Para la mayoría de los contenidos, ese es el fallback correcto —más vale una traducción publicada que un trabajo bloqueado indefinidamente—, pero es una concesión real. Para contenido en el que una persona deba dar el visto bueno sí o sí, configura un tiempo de espera amplio y genera una alerta cuando se omita; para contenido en el que la revisión sea un extra deseable, un tiempo de espera corto mantiene la canalización en marcha.
El tiempo de espera es por etapa, no por trabajo
El tiempo de espera solo determina cuánto tiempo espera esta etapa a una persona. Es independiente de lo que tarde el resto del trabajo. Como la espera se basa en eventos, un tiempo de espera largo solo te cuesta latencia hasta el resultado final si el revisor va lento; nunca recursos en segundo plano.
Activar la etapa#
humanEdit se configura como cualquier otra etapa de la canalización: con un valor predeterminado a nivel de motor en la pestaña Pipeline del motor, que opcionalmente puede sobrescribirse por solicitud. El modelo completo de dos capas se explica en Configurar la canalización; la forma específica de esta etapa es la siguiente:
{
"humanEdit": {
"enabled": true,
"provider": "internal",
"tier": "standard",
"timeoutHours": 48
}
}provider selecciona el modo: internal para tu equipo; en caso contrario, el proveedor externo. tier (standard o pro) se aplica a la Revisión externa y se ignora en la interna. timeoutHours es el límite explicado en la sección anterior. Para sobrescribirlo en un único envío, pasa este bloque dentro de pipelineConfig en la llamada a create; si lo omites, el trabajo hereda la configuración del motor.
Cuando la etapa se ejecuta, queda registrada en el trabajo en stepId: "humanEdit" con un estado de completed, failed o skipped: el mismo registro de paso que genera cada etapa. Cómo leer esos registros se explica en Observar ejecuciones de la canalización.
Una edición humana puede desviarse de las reglas de tu motor
Un traductor humano puede formular algo de una forma que entre en conflicto con tu glosario, tu voz de marca o tus instrucciones: su objetivo es traducir bien, no memorizar tu configuración. Para reconciliar automáticamente la edición humana con las reglas de tu motor, activa la siguiente etapa, evaluación de IA. Solo se ejecuta después de una etapa humana que haya generado realmente un resultado.
