高级实践 - Lingo.dev

CI/CD 本地化高级实践：工作流选择、翻译完整性校验，以及合并冲突处理。

选择工作流#

四种工作流模式基本覆盖了大多数团队的协作场景。它们在自动化程度、审核成本和分支管理整洁性上各有取舍。

工作流	适用场景	取舍
直接提交到 main	小团队，追求低阻力更新	翻译缺少审核环节
从 main 发起 PR	希望审核翻译内容的团队	需要手动审批 PR
提交到功能分支	长期维护的功能分支	翻译提交会保留在分支历史中
从功能分支发起 PR	希望按功能获得最大控制力	每个功能都要管理多个 PR

如果不确定该选哪种，建议先从“直接提交到 main”开始。它最简单，而且由于没有分支分叉，能彻底避免合并冲突。

检查翻译完整性#

--frozen 标志会在不生成新翻译的前提下，校验所有内容是否都已完成翻译。如果有任何内容缺失，它会以非零状态码退出：

bash

npx lingo.dev@latest run --frozen

你可以把它作为部署门禁，避免将未翻译内容发布上线。

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

解决合并冲突#

当分支之间的 i18n.lock 文件出现分叉时，就会产生合并冲突——通常是因为不同分支分别独立更新了翻译。

如何预防#

将翻译直接提交到 main（而不是通过功能分支处理翻译），可以彻底消除 lockfile 冲突。

通过 merge 解决#

开始合并

bash

git merge <branch-name>

删除发生冲突的 lockfile

bash

rm i18n.lock

完成合并

bash

git add .
git merge --continue

重新生成 lockfile

bash

npx lingo.dev@latest lockfile --force

这会根据当前源文件状态重新构建 lockfile，同时不会触发新的翻译。

通过 rebase 解决#

同样的方法也适用于 rebase：在每次冲突处理时删除 i18n.lock，继续 rebase，最后再重新生成 lockfile：

bash

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

下一步#

CI/CD 本地化高级实践：工作流选择、翻译完整性校验，以及合并冲突处理。

选择工作流#

四种工作流模式基本覆盖了大多数团队的协作场景。它们在自动化程度、审核成本和分支管理整洁性上各有取舍。

工作流	适用场景	取舍
直接提交到 main	小团队，追求低阻力更新	翻译缺少审核环节
从 main 发起 PR	希望审核翻译内容的团队	需要手动审批 PR
提交到功能分支	长期维护的功能分支	翻译提交会保留在分支历史中
从功能分支发起 PR	希望按功能获得最大控制力	每个功能都要管理多个 PR

如果不确定该选哪种，建议先从“直接提交到 main”开始。它最简单，而且由于没有分支分叉，能彻底避免合并冲突。

检查翻译完整性#

--frozen 标志会在不生成新翻译的前提下，校验所有内容是否都已完成翻译。如果有任何内容缺失，它会以非零状态码退出：

bash

npx lingo.dev@latest run --frozen

你可以把它作为部署门禁，避免将未翻译内容发布上线。

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

解决合并冲突#

当分支之间的 i18n.lock 文件出现分叉时，就会产生合并冲突——通常是因为不同分支分别独立更新了翻译。

如何预防#

将翻译直接提交到 main（而不是通过功能分支处理翻译），可以彻底消除 lockfile 冲突。

通过 merge 解决#

开始合并

bash

git merge <branch-name>

删除发生冲突的 lockfile

bash

rm i18n.lock

完成合并

bash

git add .
git merge --continue

重新生成 lockfile

bash

npx lingo.dev@latest lockfile --force

这会根据当前源文件状态重新构建 lockfile，同时不会触发新的翻译。

通过 rebase 解决#

同样的方法也适用于 rebase：在每次冲突处理时删除 i18n.lock，继续 rebase，最后再重新生成 lockfile：

bash

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

下一步#