Patrones avanzados

Patrones avanzados para la localización en CI/CD: elección del flujo de trabajo, comprobaciones 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 concesiones distintas en automatización, carga de revisión e higiene de ramas.

Flujo de trabajo	Ideal para	Inconveniente
Commit en main	Equipos pequeños y actualizaciones sin fricción	No hay paso de revisión para las traducciones
PR desde main	Equipos que quieren revisar las traducciones	Requiere aprobar la PR manualmente
Commit en la rama de funcionalidad	Ramas de funcionalidad de larga duración	Commits de traducción en el historial de la rama
PR desde la rama de funcionalidad	Máximo control por funcionalidad	Hay que gestionar varias PR por funcionalidad

Si no estás seguro, empieza con "Commit en main". Es el flujo de trabajo más sencillo y evita por completo los conflictos de merge, ya que no hay divergencia entre ramas.

Comprobar que las traducciones están completas#

La marca --frozen verifica que todo el contenido esté traducido sin generar traducciones nuevas. Devuelve un código de salida distinto de cero si falta algún contenido:

bash

npx lingo.dev@latest run --frozen

Úsala como puerta de despliegue para evitar publicar contenido sin traducir.

yaml

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: 20
      - run: npx lingo.dev@latest run --frozen

Resolver conflictos de merge#

Los conflictos de merge aparecen cuando el archivo i18n.lock 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 ramas de funcionalidad para las traducciones) elimina por completo los conflictos del lockfile.

Resolución mediante merge#

Inicia el merge

bash

git merge <branch-name>

Elimina el lockfile en conflicto

bash

rm i18n.lock

Completa el merge

bash

git add .
git merge --continue

Regenera el lockfile

bash

npx lingo.dev@latest lockfile --force

Esto reconstruye el lockfile a partir del estado actual de tus archivos fuente sin activar traducciones nuevas.

Resolución mediante rebase#

El mismo enfoque funciona con rebase: elimina i18n.lock en cada paso del conflicto, continúa el rebase y luego regenera el lockfile al final:

bash

git rebase <branch-name>
# On each conflict: rm i18n.lock && git add . && git rebase --continue
npx lingo.dev@latest lockfile --force

Siguientes pasos#

GitHub Actions

Configura la GitHub Action oficial

i18n.lock

Cómo el lockfile hace seguimiento del estado de las traducciones

Cómo funciona

El pipeline de localización para CI/CD

Configuración

Configura CI/CD para tu proyecto

Patrones avanzados para la localización en CI/CD: elección del flujo de trabajo, comprobaciones 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 concesiones distintas en automatización, carga de revisión e higiene de ramas.

Flujo de trabajo	Ideal para	Inconveniente
Commit en main	Equipos pequeños y actualizaciones sin fricción	No hay paso de revisión para las traducciones
PR desde main	Equipos que quieren revisar las traducciones	Requiere aprobar la PR manualmente
Commit en la rama de funcionalidad	Ramas de funcionalidad de larga duración	Commits de traducción en el historial de la rama
PR desde la rama de funcionalidad	Máximo control por funcionalidad	Hay que gestionar varias PR por funcionalidad

Si no estás seguro, empieza con "Commit en main". Es el flujo de trabajo más sencillo y evita por completo los conflictos de merge, ya que no hay divergencia entre ramas.

Comprobar que las traducciones están completas#

La marca --frozen verifica que todo el contenido esté traducido sin generar traducciones nuevas. Devuelve un código de salida distinto de cero si falta algún contenido:

bash

npx lingo.dev@latest run --frozen

Úsala como puerta de despliegue para evitar publicar contenido sin traducir.

yaml

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: 20
      - run: npx lingo.dev@latest run --frozen

Resolver conflictos de merge#

Los conflictos de merge aparecen cuando el archivo i18n.lock 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 ramas de funcionalidad para las traducciones) elimina por completo los conflictos del lockfile.

Resolución mediante merge#

Inicia el merge

bash

git merge <branch-name>

Elimina el lockfile en conflicto

bash

rm i18n.lock

Completa el merge

bash

git add .
git merge --continue

Regenera el lockfile

bash

npx lingo.dev@latest lockfile --force

Esto reconstruye el lockfile a partir del estado actual de tus archivos fuente sin activar traducciones nuevas.

Resolución mediante rebase#

El mismo enfoque funciona con rebase: elimina i18n.lock en cada paso del conflicto, continúa el rebase y luego regenera el lockfile al final:

bash

git rebase <branch-name>
# On each conflict: rm i18n.lock && git add . && git rebase --continue
npx lingo.dev@latest lockfile --force

Siguientes pasos#

GitHub Actions

Configura la GitHub Action oficial

i18n.lock

Cómo el lockfile hace seguimiento del estado de las traducciones

Cómo funciona

El pipeline de localización para CI/CD

Configuración

Configura CI/CD para tu proyecto