Patrones avanzados para localización en CI/CD: elección de flujo de trabajo, comprobación de traducciones completas y resolución de conflictos de merge.
Cómo elegir un flujo de trabajo#
Estos cuatro patrones de flujo de trabajo cubren la mayoría de las configuraciones de equipo. Cada uno implica distintos trade-offs en automatización, carga de revisión e higiene de ramas.
| Flujo de trabajo | Ideal para | Trade-off |
|---|---|---|
| Commit a main | Equipos pequeños, actualizaciones sin fricción | Sin paso de revisión para las traducciones |
| PR desde main | Equipos que quieren revisar las traducciones | Requiere aprobación manual del PR |
| Commit a feature branch | Feature branches de larga duración | Commits de traducción en el historial de la rama |
| PR desde feature branch | Máximo control por funcionalidad | Hay que gestionar varios PR por funcionalidad |
En GitHub, la Lingo.dev GitHub App resuelve la mayoría de estos casos del lado del servidor: reacciona a pushes y PRs, hace commit de las traducciones de vuelta al repositorio y no requiere runner ni secretos. Recurre a los patrones de CLI de abajo cuando la localización forme parte de tu propio pipeline.
Si no estás seguro, empieza con "Commit a main". Es el flujo de trabajo más simple y evita por completo los conflictos de merge, ya que no hay divergencia entre ramas.
Comprobar que las traducciones estén completas#
El comando lingo check verifica que todo el contenido esté traducido sin generar traducciones nuevas. Devuelve un código de salida distinto de cero si falta contenido:
lingo checkÚsalo como puerta de despliegue para evitar publicar contenido sin traducir. Instala la CLI con npm install -g @lingo.dev/cli (Node 22+) y autentica el runner con la variable de entorno LINGO_API_KEY.
name: Check translations
on: [push, pull_request]
jobs:
check:
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 check
env:
LINGO_API_KEY: ${{ secrets.LINGO_API_KEY }}Resolver conflictos de merge#
Los conflictos de merge ocurren cuando el archivo .lingo/lock.json diverge entre ramas, normalmente cuando las traducciones se actualizan de forma independiente en distintas ramas.
Prevención#
Hacer commit de las traducciones directamente en main (en lugar de usar feature branches para las traducciones) elimina por completo los conflictos del lockfile.
Resolución mediante merge#
Inicia el merge
git merge <branch-name>Elimina el lockfile en conflicto
rm .lingo/lock.jsonCompleta el merge
git add .
git merge --continueRegenera el lockfile
lingo pushAl ejecutar lingo push, se reconstruye .lingo/lock.json a partir del estado actual de tus archivos fuente como parte de la sincronización habitual.
Resolución mediante rebase#
El mismo enfoque también funciona con rebase: elimina .lingo/lock.json en cada paso del conflicto, continúa el rebase y luego ejecuta lingo push al final para regenerar el lockfile:
git rebase <branch-name>
# On each conflict: rm .lingo/lock.json && git add . && git rebase --continue
lingo push