La CLI de Lingo.dev funciona en cualquier entorno de CI/CD con Node.js. Añádela como un paso del pipeline para traducir en cada push: el lockfile garantiza que solo se procesen las cadenas modificadas, de modo que las traducciones sigan siendo rápidas y rentables a medida que crece tu proyecto.
¿Usas GitHub? Tienes dos formas de ejecutarlo
La GitHub App es la opción más sencilla en GitHub: la instalas una vez y reacciona automáticamente a los pushes y las pull requests. Sin runner, sin secreto de clave API y sin lockfile; configuras el repositorio con .lingo/config.json y un engineId.
La GitHub Action y las demás integraciones de abajo ejecutan la CLI dentro de tu propio pipeline usando i18n.json, un i18n.lock lockfile y un secreto LINGODOTDEV_API_KEY. Elige esta vía si quieres que la traducción se ejecute junto con otros pasos de CI o si no usas GitHub.
El resto de esta guía se centra en la GitHub Action y la CLI.
Cómo funciona#
El pipeline de CI/CD ejecuta la CLI como un paso después del checkout. La CLI lee tu configuración de i18n.json, compara los archivos de origen con el lockfile para identificar cambios, traduce el delta mediante un motor de localización configurado y escribe los resultados en los archivos del idioma de destino. Después, el pipeline hace commit de los archivos traducidos o abre una pull request, según el flujo de trabajo que prefieras.
Elige tu flujo de trabajo#
Hay cuatro patrones de flujo de trabajo que cubren la mayoría de las estructuras de equipo. Empieza por el más sencillo y evoluciona a medida que tu equipo crezca.
| Flujo de trabajo | Cómo funciona | Ideal para | Inconveniente |
|---|---|---|---|
| Commit a main | Traduce y hace commit directamente en main | Equipos pequeños, fricción cero | Sin paso de revisión para las traducciones |
| PR desde main | Traduce y abre una PR para revisión | Equipos que revisan traducciones | Requiere aprobación manual de la PR |
| Commit en rama de funcionalidad | Traduce al hacer push en una rama de funcionalidad | Ramas de funcionalidad de larga duración | Commits de traducción en el historial de la rama |
| PR desde rama de funcionalidad | Traduce y abre una PR desde una rama de funcionalidad | Máximo control por funcionalidad | Varias PR por funcionalidad |
Recomendación para empezar
Hacer commit en main funciona bien para la mayoría de los equipos. Las traducciones se entregan con cada push, el lockfile garantiza la consistencia y el glosario y las reglas de voz de marca del motor de localización se ocupan de la calidad. Pásate a flujos de trabajo basados en PR cuando necesites revisión humana de las traducciones.
Configuración rápida#
Guarda tu clave API de Lingo.dev como un secreto de CI/CD y añade después el paso de traducción a tu pipeline.
Lingo.dev ofrece una GitHub Action oficial que se encarga del checkout, la traducción y la creación del commit o de la PR.
¿Prefieres no tener que gestionar un archivo de flujo de trabajo, un secreto de clave API o un lockfile? La GitHub App se encarga de la localización continua en GitHub sin nada de eso: instálala una vez y configura .lingo/config.json.
Commit a main:
name: Translate
on:
push:
branches: [main]
permissions:
contents: write
jobs:
translate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: lingodotdev/lingo.dev@main
with:
api-key: ${{ secrets.LINGODOTDEV_API_KEY }}PR desde main: añade pull-request: true y un GH_TOKEN:
name: Translate
on:
push:
branches: [main]
permissions:
contents: write
pull-requests: write
jobs:
translate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: lingodotdev/lingo.dev@main
with:
api-key: ${{ secrets.LINGODOTDEV_API_KEY }}
pull-request: true
env:
GH_TOKEN: ${{ github.token }}Consulta la guía completa de integración con GitHub Actions para flujos de trabajo con ramas de funcionalidad, mensajes de commit personalizados, compatibilidad con monorepos y firma GPG.
Verificación de traducciones#
La marca --frozen y el lockfile forman parte de la GitHub Action y de la CLI. La GitHub App hace el seguimiento del estado de las traducciones en el servidor y no tiene lockfile ni equivalente a --frozen.
Usa la marca --frozen como puerta de despliegue para asegurarte de que no se publique contenido sin traducir en producción. La CLI sale con un estado distinto de cero si alguna cadena necesita traducción.
npx lingo.dev@latest run --frozenAñádelo como un paso independiente del pipeline antes del despliegue:
- name: Verify translations
run: npx lingo.dev@latest run --frozenFlujos de trabajo para monorepos#
En monorepos con varios paquetes, cada uno con sus propios archivos de traducción, usa la opción working-directory para apuntar a paquetes concretos:
- uses: lingodotdev/lingo.dev@main
with:
api-key: ${{ secrets.LINGODOTDEV_API_KEY }}
working-directory: apps/webConflictos de fusión#
Esto se aplica a la GitHub Action y a la CLI. La GitHub App no usa lockfile, así que no tiene conflictos de i18n.lock que resolver.
El lockfile (i18n.lock) puede entrar en conflicto cuando se fusionan ramas con cambios de traducción. La solución es sencilla: elimina el lockfile en conflicto, completa la fusión y vuelve a generarlo:
git merge feature-branch
rm i18n.lock
git add .
git merge --continue
npx lingo.dev@latest lockfile --forceEl comando lockfile --force reconstruye el lockfile a partir del estado actual de tus archivos de origen sin activar nuevas traducciones. Consulta la guía de patrones avanzados de integración para conocer estrategias de resolución basadas en rebase y de prevención de conflictos.
