Lingo.dev automatiza tu localización en CI/CD. Hay dos formas de hacerlo: con la GitHub App, que responde a tus pushes y pull requests desde el servidor, o ejecutando la CLI dentro de tu propio pipeline. Ambas mantienen las traducciones sincronizadas con cada cambio y solo procesan las cadenas que realmente han cambiado, para que la localización siga siendo rápida y rentable a medida que crece tu proyecto.
¿Usas GitHub? Empieza por la App
La GitHub App es la opción recomendada si usas GitHub. La instalas una vez y localiza en cada push y pull request, sin runner, sin secretos de CI y sin ningún lockfile que mantener. Si no usas GitHub, o prefieres que la traducción se ejecute junto con el resto de pasos de CI, ejecuta la CLI en tu propio pipeline.
Opción 1: GitHub App (recomendada)#
La GitHub App es la forma más sencilla de usar la localización continua. Supervisa tu repositorio y traduce desde el servidor, así que no tienes que instalar nada en tu pipeline ni guardar ninguna clave API como secreto de CI.
La configuración se hace una sola vez:
- Instala la GitHub App de Lingo.dev en tu repositorio.
- Haz commit de un
.lingo/config.jsoncon tuorgId,engineId, idioma de origen, idiomas de destino y los archivos que quieres traducir. Ejecutalingo initylingo linken local para generarlo y luego haz commit del resultado. - Haz push.
A partir de ahí, la App se encarga por ti de ambos estilos de flujo de trabajo:
- Cuando haces push a tu rama predeterminada, hace commit de las traducciones en esa misma rama.
- En una pull request, añade las traducciones a esa PR para que puedas revisarlas antes de fusionarla.
Como la App gestiona el estado de la traducción desde el servidor, no hay ningún lockfile en el repositorio que pueda provocar conflictos ni ningún paso de verificación que tengas que conectar: simplemente mantiene tus idiomas de destino sincronizados con el origen.
Opción 2: CLI en tu propio pipeline#
Si no usas GitHub, o quieres que la localización se ejecute como un paso explícito junto a tus jobs de compilación y pruebas, ejecuta tú mismo la CLI. Funciona en cualquier entorno de CI con Node.js 22 o posterior: GitHub Actions, GitLab CI, Bitbucket Pipelines o cualquier otro.
El flujo siempre es el mismo:
- Instala
@lingo.dev/cli. - Autentícate con tu clave API mediante la variable de entorno
LINGO_API_KEY. - Ejecuta
lingo pushpara traducir las cadenas modificadas. - Haz commit de los resultados o abre una pull request desde tu job.
Guarda tu clave API de Lingo.dev como secreto de CI y expónla como LINGO_API_KEY. El .lingo/config.json versionado indica a la CLI qué debe traducir, y el .lingo/lock.json versionado (regenerado por lingo push) registra el estado para que solo se procesen las cadenas modificadas.
Ejemplo mínimo con GitHub Actions#
Este flujo de trabajo instala la CLI, traduce en cada push a main y hace commit de los resultados:
name: Localize
on:
push:
branches: [main]
permissions:
contents: write
jobs:
localize:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm install -g @lingo.dev/cli
- run: lingo push
env:
LINGO_API_KEY: ${{ secrets.LINGO_API_KEY }}
- name: Commit translations
run: |
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
git add .
git commit -m "chore: update translations" || echo "No changes"
git pushEsas mismas dos líneas, primero npm install -g @lingo.dev/cli y luego lingo push, se pueden usar en un bloque script: de GitLab CI o en un paso de Bitbucket Pipelines. Configura LINGO_API_KEY como variable de CI enmascarada/protegida en esas plataformas.
Primera ejecución y nuevos idiomas
La primera vez que lo ejecutes en CI, o cada vez que añadas un idioma de destino, usa lingo push --backfill-missing para que se traduzcan todas las cadenas existentes al nuevo idioma. A partir de ahí, con un simple lingo push se traduce solo el delta.
¿Commit o pull request?#
Elijas la opción que elijas, sigues decidiendo cómo llegan las traducciones:
| Enfoque | Cómo funciona | Ideal para | Inconveniente |
|---|---|---|---|
| Commit directo | Las traducciones se confirman en la rama que ha cambiado | Equipos pequeños, fricción cero | Sin paso de revisión para las traducciones |
| Pull request | Las traducciones llegan en una PR para revisión antes de fusionarse | Equipos que revisan traducciones | Requiere aprobación de la PR |
La GitHub App te da ambas opciones automáticamente: hace commit en los pushes a tu rama predeterminada y añade las traducciones a las PR abiertas. En tu propio pipeline, decides tú: hacer commit de los resultados como se muestra arriba o hacer que el job abra una pull request en lugar de hacer push a la rama.
Verificar las traducciones antes del despliegue#
Para asegurarte de que no se publique contenido sin traducir, añade lingo check como control antes del paso de despliegue. Devuelve un estado distinto de cero cuando todavía hay cadenas pendientes de traducir:
- name: Verify translations
run: lingo checkLa GitHub App mantiene los idiomas sincronizados de forma continua, así que un paso de verificación específico resulta especialmente útil cuando ejecutas la CLI por tu cuenta.
Monorrepos#
En monorrepos donde cada paquete tiene su propio .lingo/config.json, limita la ejecución a un paquete pasando un glob, o ejecuta la CLI desde el directorio de ese paquete:
lingo push "apps/web/**"