Welcome back, {name}. Your trial ends soon.{' '}
Compare plans
);
}
```
句子、名称和链接都保留在组件中，[`npx gt translate`](/docs/cli/reference/commands/translate) 会将整个 block 作为一个单元翻译，同时让名称保持原样、不被翻译。
* **更快。** 在上面的横幅中，文案、变量和链接是一起编辑的。CLI 会在构建前提取该 block，为有变更的内容生成译文，并复用已完成的匹配翻译。这样每次修改文案时，都无需再处理源键和富文本映射。
* **按用量计费。** 在 SimpleLocalize 中，随着目录规模或审校团队的扩大，成员和键的额度都会影响你的费用。General Translation 的[按用量定价](https://generaltranslation.com/pricing)不收取席位费，也不按键数量分档，因此邀请新的审校人员不会增加席位费用。
* **以 JSX 结构作为上下文。** 在横幅旁边保留一条备注，例如“Trial 指软件订阅试用”。提取出的结构会将问候语和定价链接放在一起，审校人员可以在[仪表板](/kb/review-translations)中修正生成的措辞。[上下文指南](/kb/ai-translation-context)介绍了如何添加周边源代码行和共享术语。
* **风险更低。** 先从应用中现有的 i18next 或 next-intl 消息目录入手，并保留已审校的译文，之后再逐步引入内联 JSX。对于 React 和 Next.js 代码仓库，配置好的 Locadex **生成代码** 运行会为新出现的未标记文本建议包裹方式，并以可供审查的拉取请求形式提交。如果应用使用采用 MIT 许可证的 `gt-react` 或 `gt-next`，并配置为在本地加载所有译文，那么无需 GT 账户，也无需调用运行时服务，即可渲染译文。
## 何时更适合选择 SimpleLocalize
以下情况更适合选择 SimpleLocalize：译者或审校人员希望通过浏览器扩展直接在线上站点编辑文本；你希望让用户提交翻译建议；你需要为个别客户提供不同的措辞；原生移动应用需要通过 OTA (空中下载) 方式更新字符串；或者你的应用使用 [Flutter ARB、XLIFF、Java properties 或 Excel](https://simplelocalize.io/docs/file-formats/arb/) 等文件格式。
## 从 SimpleLocalize 迁移到 General Translation
1. **导出并备份。** 从 SimpleLocalize 导出相互对应的源文件快照，以及完整且已审校的目标文件，并保留一份备份。请先补全未完成的区域设置，以免未翻译的条目被当作译文导入。
2. **暂停 SimpleLocalize 的写入。** 在 General Translation 写入任何文件之前，先暂停其 GitHub App，并从 CI 中移除 SimpleLocalize 的下载步骤。如果两个工具写入相同的文件，以最后写入的一方为准。
3. **设置上下文。** 为这些文件配置 `gt.config.json`；对于 JSON 或 YAML 文件，将键的描述和长度限制迁移到[键级元数据](/docs/cli/reference/keyed-metadata)中；并将词汇表导入上下文分组，确保首批翻译即可用上这些信息。
4. **上传。** 运行 [`npx gt upload`](/docs/cli/reference/commands/upload)，导入与源快照相对应的目标文件。
5. **翻译并验证。** 运行 [`npx gt translate`](/docs/cli/reference/commands/translate)，然后在应用中检查任一区域设置的效果。如果使用 i18next 或 next-intl，可以继续沿用现有的库，由 CLI [生成后续翻译](/docs/cli/guides/generating-translations)；是否将文案改为内联，可以之后再单独决定。
## General Translation 能否替代 SimpleLocalize？
可以。你已审校的译文、键描述和词汇表都可以沿用，使用 i18next 或 next-intl 的应用也可以继续使用原有的库。改变的是工作流程：翻译直接在构建过程中基于组件或文件完成，而不再依赖同步的目录；你还可以按功能逐步将文案以内联方式迁移到 [`