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 del lado del servidor, o con el CLI ejecutándose dentro de tu propio pipeline. Ambas mantienen las traducciones sincronizadas con cada cambio y procesan solo las cadenas que realmente cambiaron, para que la localización siga siendo rápida y rentable a medida que tu proyecto crece.
¿Usas GitHub? Empieza con 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 lockfiles que administrar. Si no usas GitHub, o prefieres que la traducción se ejecute junto con tus otros pasos de CI, ejecuta el CLI en tu propio pipeline.
Opción 1: GitHub App (recomendada)#
La GitHub App es la forma más simple de ejecutar localización continua. Supervisa tu repositorio y traduce del lado del servidor, así que no tienes que instalar nada en tu pipeline ni guardar una clave de 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 linklocalmente 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 de vuelta en esa rama.
- En un pull request, agrega las traducciones a ese PR para que puedas hacer la revisión antes del merge.
Como la App lleva el estado de la traducción del lado del servidor, no hay lockfile en tu repositorio que pueda generar conflictos ni ningún paso de verificación que tengas que conectar: simplemente mantiene tus idiomas de destino sincronizados con el idioma de 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 el CLI por tu cuenta. 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 de API a través de la variable de entorno
LINGO_API_KEY. - Ejecuta
lingo pushpara traducir las cadenas modificadas. - Haz commit de los resultados o abre un pull request desde tu job.
Guarda tu clave de API de Lingo.dev como secreto de CI y expónla como LINGO_API_KEY. El .lingo/config.json incluido en el commit le indica al CLI qué traducir, y el .lingo/lock.json incluido en el commit (regenerado por lingo push) lleva el estado para que solo se procesen las cadenas modificadas.
Ejemplo mínimo de GitHub Actions#
Este flujo de trabajo instala el CLI, traduce en cada push a main y hace commit de los resultados de vuelta:
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 pushLas mismas dos líneas — npm install -g @lingo.dev/cli y luego lingo push — se pueden usar en un bloque script: de GitLab CI o en un step de Bitbucket Pipelines. Configura LINGO_API_KEY como una variable de CI enmascarada/protegida en esas plataformas.
Primera ejecución e idiomas nuevos
La primera vez que lo ejecutes en CI, o cada vez que agregues un idioma de destino, usa lingo push --backfill-missing para que todas las cadenas existentes se traduzcan al nuevo idioma. Después de eso, un simple lingo push traduce solo el delta.
¿Commit o pull request?#
Elijas la ruta que elijas, tú decides cómo se incorporan las traducciones:
| Enfoque | Cómo funciona | Ideal para | Trade-off |
|---|---|---|---|
| Commit directo | Las traducciones se confirman en la rama que cambió | Equipos pequeños, cero fricción | Sin paso de revisión para las traducciones |
| Pull request | Las traducciones llegan en un PR para revisión antes del merge | Equipos que revisan traducciones | Requiere aprobación del PR |
La GitHub App te ofrece ambas automáticamente: hace commit en los pushes a tu rama predeterminada y agrega las traducciones a los PR abiertos. En tu propio pipeline, la decisión es tuya: haz commit de los resultados como se muestra arriba, o haz que el job abra un pull request en lugar de hacer push a la rama.
Verificar traducciones antes del deploy#
Para asegurarte de que no se publique contenido sin traducir, agrega lingo check como control antes de tu paso de deploy. Devuelve un estado distinto de cero cuando todavía hay cadenas pendientes de traducción:
- name: Verify translations
run: lingo checkLa GitHub App mantiene los idiomas sincronizados de forma continua, así que un paso de verificación dedicado resulta especialmente útil cuando ejecutas el CLI por tu cuenta.
Monorepos#
En monorepos donde cada paquete tiene su propio .lingo/config.json, limita la ejecución a un paquete pasando un glob, o ejecuta el CLI desde el directorio de ese paquete:
lingo push "apps/web/**"