Replexica SDK 演进全解从 replexica/sdk 到 Lingo.dev 的本地化引擎实现原理与迁移指南【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica本篇技术指南以 legacy/sdk/CHANGELOG.md 的版本演进为骨架结合当前仓库中 packages/sdk/src/index.ts 的完整实现源码系统梳理 Replexica 定位LocalizationSDK 从 0.1.0 到 0.7.17 的核心能力演进、底层调用链与配置参数细节并给出从已弃用的replexica/sdk迁移到lingo.dev的完整方案。读完本文你将掌握该 SDK 的分批请求机制、重试与限流策略、HTML 本地化实现、语言识别与成本预估等核心原理能够直接基于源码定位问题并完成迁移。一、SDK 的定位API 调用层的独立抽取回顾 legacy/sdk/CHANGELOG.md 的起点replexica/sdk在 0.1.0对应 PR #142版本中完成了最关键的一次架构决策将 API 调用逻辑从 CLI 中抽取为独立 SDK 包。这意味着CLI 与后续所有工具共享同一套引擎调用层API 请求、响应解析、参数校验等逻辑被收敛到单一模块便于集中演进SDK 成为 CLI 与 Lingo.dev 本地化平台之间的协议边界。从当前仓库的 packages/sdk/src/index.ts 可以确认这一架构延续至今核心类LingoDotDevEngine封装了全部 API 交互而 CLI、CI 集成、Directus 等均通过它发起请求。二、版本演进时间线与能力里程碑原 CHANGELOG 记录了 0.1.0 → 0.7.17 的完整版本史其中掺杂了大量replexica/spec、lingo.dev的依赖更新。下表将其中的功能型变更提炼出来形成能力里程碑版本类型核心变更源码印证当前仓库0.1.0Minor将 API 调用抽取为独立 SDK 包LingoDotDevEngine类整体封装0.2.0Minor为 CLI 增加多源本地化multisource localization支持reference参数字段0.3.0Minor更新 locale code 解析逻辑normalizeLocale/normalizedLocaleCodeSchema0.4.0Minor增加 format-specific 方法面向特定内容格式的本地化方法localizeHtml、localizeChat等0.5.0Minor实现recognizeLocale语言识别与.localizeHtmlrecognizeLocale()方法0.6.0Minor引入 fast mode快速模式更新默认 batch size 上限fast参数、batchSize配置0.7.0Minor新增batchLocalizeText单文本多目标语言批量本地化batchLocalizeText()方法0.7.1Patch降低默认 batch size 以避免触发限流过滤不存在的 keysbatchSize默认 25≤2500.7.3Patch将 jsdom import 移入 HTML handler 函数内部延迟加载localizeHtml()内的动态import(jsdom)0.7.10–0.7.9 等Patchreplexica/spec系列依赖更新0.9.0 → 0.24.0版本对齐0.7.11Patch为 legacy 包添加 proxies、deprecation message 与 deprecation warninglegacy/sdk/index.js的console.warn0.7.13Patch为社区贡献demo apps 等创建独立空间新增 dependency overrides 修补安全漏洞pnpm-workspace.yamloverrides0.7.12、0.7.14–0.7.17Patch依赖更新至lingo.dev0.70.4 → 0.138.5包改名后的版本延续三、引擎配置参数来自源码的完整字段说明当前实现packages/sdk/src/index.ts通过 zod schema 定义并校验引擎配置参数及其默认值如下参数类型默认值取值范围/说明apiKeystring必填请求头X-API-Key的来源apiUrlstring(URL)https://api.lingo.dev可指向自建/代理端点batchSizeint250且≤250每个请求最多携带的键数量idealBatchItemSizeint2500且≤2500按词数切分 chunk 的参考阈值engineIdstring可选随请求透传给服务端maxRetriesint3瞬时失败5xx/网络错误后的最大重试次数0关闭重试retryDelayMsint500指数退避基础延迟毫秒其中两个 batch 参数共同决定分块策略见 extractPayloadChunksSDK 逐键累积 payload当当前 chunk 的累计词数超过idealBatchItemSize、或键数量达到batchSize、或已到 payload 末尾时将当前 chunk 发出。这正是 0.7.1 中降低默认 batch size 避免触发限流的工程落地——将batchSize从更大值收敛到 25以单请求更小的体积换取更低的 API 限流风险。3.1 实例化与调用示例import { LingoDotDevEngine } from lingo.dev/sdk; const engine new LingoDotDevEngine({ apiKey: YOUR_API_KEY, // 以下均为可选展示默认值与边界 apiUrl: https://api.lingo.dev, // 默认 batchSize: 25, // 1–250 idealBatchItemSize: 250, // 1–2500 maxRetries: 3, // 0 表示不重试 retryDelayMs: 500, // 基础退避延迟 }); const localized await engine.localizeText(Hello, world, { sourceLocale: en, targetLocale: es, });四、本地化请求的核心链路从分块到重试4.1 请求结构与校验localizationParamsSchema源码定义了每次本地化请求的参数sourceLocale可为null由服务端自动识别源语言或合法 locale codetargetLocale目标语言代码fast可选布尔值开启快速模式0.6.0 引入更快但质量可能略低reference可选的参考翻译字典多源本地化的数据载体对应 0.2.0 能力hints可选提示词集合Recordstring, string[]filePath可选元数据随请求透传triggerTypecli或ci用于区分触发来源。值得注意的细节是 locale 规范化源码对 locale code 采用宽松校验、严格传输策略normalizedLocaleCodeSchema允许 Android 风格pt-rPT、下划线风格pt_PT通过校验但在发往 API 前统一转换为规范 BCP 47 形式文件路径则保留原始写法例如 Android 资源目录values-pt-rPT/不受影响。这与 0.3.0更新 locale code 解析逻辑一脉相承。4.2 请求体与端点每个 chunk 通过POST {apiUrl}/process/localize发送见 localizeChunk请求体包含{ params: { fast: false }, sourceLocale: en, targetLocale: es, data: { key1: text1 }, reference: { es: { key1: texto1 } }, hints: {}, sessionId: cuid2 生成的会话标识, triggerType: cli, metadata: { filePath: src/i18n/en.json } }sessionId由paralleldrive/cuid2生成用于服务端串联同一次会话的多次请求。所有请求携带Content-Type: application/json; charsetutf-8与X-API-Key两个请求头。4.3 重试与指数退避0.7.17 时期的 CHANGELOG 未显式记录重试逻辑但当前 fetchWithRetry 实现对应新包 0.16.5 的变更提供了可验证的细节仅对瞬时失败重试HTTP 5xx 与网络层错误4xx 直接返回交由上层处理指数退避 full jitter实际等待时间为[0, retryDelayMs * 2 ** attempt]区间内的随机值避免大量客户端在服务恢复瞬间同步冲击见 backoffDelayAbortSignal 中止的请求永不重试重试循环每次迭代前都会检查signal?.aborted中止后立即抛错。4.4 进度回调与事件埋点_localizeRaw在每处理完一个 chunk 后会以Math.round((i 1) / chunkedPayload.length * 100)计算 0–100 的进度并回调。同时localizeObject、localizeText、localizeChat等方法在成功/失败路径都会通过trackEvent上报LOCALIZE_START/LOCALIZE_SUCCESS/LOCALIZE_ERROR事件当前仓库新版本中这些事件还支持按 organization 分组聚合便于可观测性分析。五、面向特定格式的方法族0.4.0 与 0.5.0 的核心产出5.1 方法总览方法输入输出实现要点localizeObject任意嵌套对象同结构对象递归提取字符串值走通用分块管线localizeText单条字符串字符串包装为{ text }键调用_localizeRawbatchLocalizeText文本 targetLocales[]字符串数组对每个目标语言并行Promise.all调用localizeText0.7.0 引入localizeStringArray字符串数组有序字符串数组映射为item_0/item_1/...键按序还原localizeChat{name, text}[]同名结构数组映射为chat_i键保留发言人姓名0.4.0 format-specific 代表localizeHtmlHTML 字符串本地化后的 HTML 字符串jsdom 解析 路径寻址回写见下节batchLocalizeText是 0.7.0 的里程碑能力只需一段源文本和一组目标语言即可一次性获得多语言结果适合单文案多语言发布的场景。5.2 HTML 本地化的实现细节localizeHtml源码是 format-specific 方法的代表作其处理流程清晰可验证DOM 解析使用jsdom的JSDOM将 HTML 字符串解析为 DOM。这里印证了 0.7.3 的优化——jsdom通过动态import(jsdom)在 handler 函数内部按需加载避免在仅使用文本/对象本地化时付出引入大型依赖的代价可提取内容白名单文本节点所有非空文本可本地化属性meta content、img alt、input placeholder、a title排除标签script、style及其子树路径寻址每个提取项以类似body/2/0或img/0/1#alt的索引路径作为键根节点 兄弟节点索引 可选#属性名本地化完成后按路径回写 DOM语言属性更新回写完成后将html lang设置为targetLocale序列化输出最终通过dom.serialize()输出完整 HTML。该设计保证了 HTML 的结构、样式与脚本不被破坏仅替换文本内容与可本地化属性。六、语言识别与成本预估6.1 recognizeLocale识别文本语言0.5.0 引入的recognizeLocale源码向POST {apiUrl}/process/recognize发送{ text }返回服务端识别的 locale code如en、es。其典型用途是当sourceLocale未知时先识别源语言再执行翻译或用于多语言混合内容的预处理。6.2 estimate翻译前成本预估当前 SDK对应新包 0.17.0新增了estimate方法源码向POST {apiUrl}/process/estimate提交每个目标语言的源字符数返回近似成本CostEstimate类型。服务端按chars → tokens启发式估算字段包括{ approximate: true, totals: { sourceChars: number, estimatedOutputTokens: number, estimatedLlmCostUsd: number, estimatedLocalizationCostUsd: number, estimatedTotalCostUsd: number }, byLocale: [{ targetLocale, sourceChars, estimatedOutputTokens, estimatedCostUsd }] }注意该结果是纯服务端计算不产生翻译、不存储、不计费适合在正式执行前评估成本。CLI 侧对应的run --estimate命令即复用此能力。七、弃用与迁移从 replexica/sdk 到 lingo.dev7.1 弃用链路0.7.11 之后CHANGELOG 0.7.11 记录了为 legacy packages 添加 proxies、deprecation message 与 deprecation warning。当前 legacy/sdk 目录完整保留了这套弃用机制legacy/sdk/package.json 中声明deprecated: Replexica is now Lingo.dev! ...描述为[DEPRECATED]legacy/sdk/index.js 在模块加载时通过console.warn打印黄色警告随后export * from lingo.dev/sdk完成透明转发legacy/sdk/index.d.ts 同样export * from lingo.dev/sdk保证类型可用。也就是说即使仍安装replexica/sdk实际执行的也是lingo.dev的实现——旧包只是代理壳。版本号 0.7.17 之后不再独立演进依赖随lingo.dev0.70.4 → 0.138.5同步更新。7.2 类名层面的兼容与弃用在当前 packages/sdk/src/index.ts 中ReplexicaEngine与LingoEngine被标记为deprecated二者均继承自LingoDotDevEngine仅在构造时打印一次性弃用警告。新代码应直接使用LingoDotDevEngine。7.3 迁移步骤移除旧依赖npm uninstall replexica/sdk安装新包npm install lingo.dev安装方式见 packages/sdk/README.md替换导入语句import { ... } from replexica/sdk→import { ... } from lingo.dev/sdk替换类名ReplexicaEngine/LingoEngine→LingoDotDevEngine验证配置项apiKey、apiUrl、batchSize、idealBatchItemSize等字段语义不变可直接沿用。八、依赖安全与漏洞修复0.7.13CHANGELOG 0.7.13 记录了通过 dependency overrides 修复的漏洞清单涉及picomatch、qs、unhead/vue、postcss、ajv、launch-editor、js-yaml3.x 与 4.x 两条、joi等传递依赖。这一实践在当前仓库的 pnpm-workspace.yaml overrides 中仍可见其延续如js-yaml4 4.3.1: 4.3.1、postcss8 8.5.23: 8.5.23是 monorepo 场景下通过单一文件集中收敛依赖版本、规避npm audit报漏洞的标准做法。九、总结从replexica/sdk的 0.1.0API 抽取到 0.7.17全量代理转发至lingo.dev这条演进线清晰地展示了能力分层SDK 独立→ 能力扩展格式方法、快速模式、批量、语言识别→ 工程加固分块限流、延迟加载、漏洞修复→ 品牌与包名收敛迁移与弃用。当前仓库 packages/sdk/src/index.ts 是这一演进的最终形态也是理解lingo.dev本地化引擎调用协议的最佳源码参考——包括配置校验、locale 规范化、分块策略、指数退避重试、HTML 路径回写与成本预估等全部关键机制。对于需要深入定制的开发者建议按以下路径继续阅读源码配置 Schema 与校验 → 分块与重试 → 各本地化方法 → HTML 本地化 → 识别与预估并结合 packages/sdk/CHANGELOG.md 了解新版本的能力增量。【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Replexica SDK 演进全解：从 @replexica/sdk 到 Lingo.dev 的本地化引擎实现原理与迁移指南
Replexica SDK 演进全解从 replexica/sdk 到 Lingo.dev 的本地化引擎实现原理与迁移指南【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica本篇技术指南以 legacy/sdk/CHANGELOG.md 的版本演进为骨架结合当前仓库中 packages/sdk/src/index.ts 的完整实现源码系统梳理 Replexica 定位LocalizationSDK 从 0.1.0 到 0.7.17 的核心能力演进、底层调用链与配置参数细节并给出从已弃用的replexica/sdk迁移到lingo.dev的完整方案。读完本文你将掌握该 SDK 的分批请求机制、重试与限流策略、HTML 本地化实现、语言识别与成本预估等核心原理能够直接基于源码定位问题并完成迁移。一、SDK 的定位API 调用层的独立抽取回顾 legacy/sdk/CHANGELOG.md 的起点replexica/sdk在 0.1.0对应 PR #142版本中完成了最关键的一次架构决策将 API 调用逻辑从 CLI 中抽取为独立 SDK 包。这意味着CLI 与后续所有工具共享同一套引擎调用层API 请求、响应解析、参数校验等逻辑被收敛到单一模块便于集中演进SDK 成为 CLI 与 Lingo.dev 本地化平台之间的协议边界。从当前仓库的 packages/sdk/src/index.ts 可以确认这一架构延续至今核心类LingoDotDevEngine封装了全部 API 交互而 CLI、CI 集成、Directus 等均通过它发起请求。二、版本演进时间线与能力里程碑原 CHANGELOG 记录了 0.1.0 → 0.7.17 的完整版本史其中掺杂了大量replexica/spec、lingo.dev的依赖更新。下表将其中的功能型变更提炼出来形成能力里程碑版本类型核心变更源码印证当前仓库0.1.0Minor将 API 调用抽取为独立 SDK 包LingoDotDevEngine类整体封装0.2.0Minor为 CLI 增加多源本地化multisource localization支持reference参数字段0.3.0Minor更新 locale code 解析逻辑normalizeLocale/normalizedLocaleCodeSchema0.4.0Minor增加 format-specific 方法面向特定内容格式的本地化方法localizeHtml、localizeChat等0.5.0Minor实现recognizeLocale语言识别与.localizeHtmlrecognizeLocale()方法0.6.0Minor引入 fast mode快速模式更新默认 batch size 上限fast参数、batchSize配置0.7.0Minor新增batchLocalizeText单文本多目标语言批量本地化batchLocalizeText()方法0.7.1Patch降低默认 batch size 以避免触发限流过滤不存在的 keysbatchSize默认 25≤2500.7.3Patch将 jsdom import 移入 HTML handler 函数内部延迟加载localizeHtml()内的动态import(jsdom)0.7.10–0.7.9 等Patchreplexica/spec系列依赖更新0.9.0 → 0.24.0版本对齐0.7.11Patch为 legacy 包添加 proxies、deprecation message 与 deprecation warninglegacy/sdk/index.js的console.warn0.7.13Patch为社区贡献demo apps 等创建独立空间新增 dependency overrides 修补安全漏洞pnpm-workspace.yamloverrides0.7.12、0.7.14–0.7.17Patch依赖更新至lingo.dev0.70.4 → 0.138.5包改名后的版本延续三、引擎配置参数来自源码的完整字段说明当前实现packages/sdk/src/index.ts通过 zod schema 定义并校验引擎配置参数及其默认值如下参数类型默认值取值范围/说明apiKeystring必填请求头X-API-Key的来源apiUrlstring(URL)https://api.lingo.dev可指向自建/代理端点batchSizeint250且≤250每个请求最多携带的键数量idealBatchItemSizeint2500且≤2500按词数切分 chunk 的参考阈值engineIdstring可选随请求透传给服务端maxRetriesint3瞬时失败5xx/网络错误后的最大重试次数0关闭重试retryDelayMsint500指数退避基础延迟毫秒其中两个 batch 参数共同决定分块策略见 extractPayloadChunksSDK 逐键累积 payload当当前 chunk 的累计词数超过idealBatchItemSize、或键数量达到batchSize、或已到 payload 末尾时将当前 chunk 发出。这正是 0.7.1 中降低默认 batch size 避免触发限流的工程落地——将batchSize从更大值收敛到 25以单请求更小的体积换取更低的 API 限流风险。3.1 实例化与调用示例import { LingoDotDevEngine } from lingo.dev/sdk; const engine new LingoDotDevEngine({ apiKey: YOUR_API_KEY, // 以下均为可选展示默认值与边界 apiUrl: https://api.lingo.dev, // 默认 batchSize: 25, // 1–250 idealBatchItemSize: 250, // 1–2500 maxRetries: 3, // 0 表示不重试 retryDelayMs: 500, // 基础退避延迟 }); const localized await engine.localizeText(Hello, world, { sourceLocale: en, targetLocale: es, });四、本地化请求的核心链路从分块到重试4.1 请求结构与校验localizationParamsSchema源码定义了每次本地化请求的参数sourceLocale可为null由服务端自动识别源语言或合法 locale codetargetLocale目标语言代码fast可选布尔值开启快速模式0.6.0 引入更快但质量可能略低reference可选的参考翻译字典多源本地化的数据载体对应 0.2.0 能力hints可选提示词集合Recordstring, string[]filePath可选元数据随请求透传triggerTypecli或ci用于区分触发来源。值得注意的细节是 locale 规范化源码对 locale code 采用宽松校验、严格传输策略normalizedLocaleCodeSchema允许 Android 风格pt-rPT、下划线风格pt_PT通过校验但在发往 API 前统一转换为规范 BCP 47 形式文件路径则保留原始写法例如 Android 资源目录values-pt-rPT/不受影响。这与 0.3.0更新 locale code 解析逻辑一脉相承。4.2 请求体与端点每个 chunk 通过POST {apiUrl}/process/localize发送见 localizeChunk请求体包含{ params: { fast: false }, sourceLocale: en, targetLocale: es, data: { key1: text1 }, reference: { es: { key1: texto1 } }, hints: {}, sessionId: cuid2 生成的会话标识, triggerType: cli, metadata: { filePath: src/i18n/en.json } }sessionId由paralleldrive/cuid2生成用于服务端串联同一次会话的多次请求。所有请求携带Content-Type: application/json; charsetutf-8与X-API-Key两个请求头。4.3 重试与指数退避0.7.17 时期的 CHANGELOG 未显式记录重试逻辑但当前 fetchWithRetry 实现对应新包 0.16.5 的变更提供了可验证的细节仅对瞬时失败重试HTTP 5xx 与网络层错误4xx 直接返回交由上层处理指数退避 full jitter实际等待时间为[0, retryDelayMs * 2 ** attempt]区间内的随机值避免大量客户端在服务恢复瞬间同步冲击见 backoffDelayAbortSignal 中止的请求永不重试重试循环每次迭代前都会检查signal?.aborted中止后立即抛错。4.4 进度回调与事件埋点_localizeRaw在每处理完一个 chunk 后会以Math.round((i 1) / chunkedPayload.length * 100)计算 0–100 的进度并回调。同时localizeObject、localizeText、localizeChat等方法在成功/失败路径都会通过trackEvent上报LOCALIZE_START/LOCALIZE_SUCCESS/LOCALIZE_ERROR事件当前仓库新版本中这些事件还支持按 organization 分组聚合便于可观测性分析。五、面向特定格式的方法族0.4.0 与 0.5.0 的核心产出5.1 方法总览方法输入输出实现要点localizeObject任意嵌套对象同结构对象递归提取字符串值走通用分块管线localizeText单条字符串字符串包装为{ text }键调用_localizeRawbatchLocalizeText文本 targetLocales[]字符串数组对每个目标语言并行Promise.all调用localizeText0.7.0 引入localizeStringArray字符串数组有序字符串数组映射为item_0/item_1/...键按序还原localizeChat{name, text}[]同名结构数组映射为chat_i键保留发言人姓名0.4.0 format-specific 代表localizeHtmlHTML 字符串本地化后的 HTML 字符串jsdom 解析 路径寻址回写见下节batchLocalizeText是 0.7.0 的里程碑能力只需一段源文本和一组目标语言即可一次性获得多语言结果适合单文案多语言发布的场景。5.2 HTML 本地化的实现细节localizeHtml源码是 format-specific 方法的代表作其处理流程清晰可验证DOM 解析使用jsdom的JSDOM将 HTML 字符串解析为 DOM。这里印证了 0.7.3 的优化——jsdom通过动态import(jsdom)在 handler 函数内部按需加载避免在仅使用文本/对象本地化时付出引入大型依赖的代价可提取内容白名单文本节点所有非空文本可本地化属性meta content、img alt、input placeholder、a title排除标签script、style及其子树路径寻址每个提取项以类似body/2/0或img/0/1#alt的索引路径作为键根节点 兄弟节点索引 可选#属性名本地化完成后按路径回写 DOM语言属性更新回写完成后将html lang设置为targetLocale序列化输出最终通过dom.serialize()输出完整 HTML。该设计保证了 HTML 的结构、样式与脚本不被破坏仅替换文本内容与可本地化属性。六、语言识别与成本预估6.1 recognizeLocale识别文本语言0.5.0 引入的recognizeLocale源码向POST {apiUrl}/process/recognize发送{ text }返回服务端识别的 locale code如en、es。其典型用途是当sourceLocale未知时先识别源语言再执行翻译或用于多语言混合内容的预处理。6.2 estimate翻译前成本预估当前 SDK对应新包 0.17.0新增了estimate方法源码向POST {apiUrl}/process/estimate提交每个目标语言的源字符数返回近似成本CostEstimate类型。服务端按chars → tokens启发式估算字段包括{ approximate: true, totals: { sourceChars: number, estimatedOutputTokens: number, estimatedLlmCostUsd: number, estimatedLocalizationCostUsd: number, estimatedTotalCostUsd: number }, byLocale: [{ targetLocale, sourceChars, estimatedOutputTokens, estimatedCostUsd }] }注意该结果是纯服务端计算不产生翻译、不存储、不计费适合在正式执行前评估成本。CLI 侧对应的run --estimate命令即复用此能力。七、弃用与迁移从 replexica/sdk 到 lingo.dev7.1 弃用链路0.7.11 之后CHANGELOG 0.7.11 记录了为 legacy packages 添加 proxies、deprecation message 与 deprecation warning。当前 legacy/sdk 目录完整保留了这套弃用机制legacy/sdk/package.json 中声明deprecated: Replexica is now Lingo.dev! ...描述为[DEPRECATED]legacy/sdk/index.js 在模块加载时通过console.warn打印黄色警告随后export * from lingo.dev/sdk完成透明转发legacy/sdk/index.d.ts 同样export * from lingo.dev/sdk保证类型可用。也就是说即使仍安装replexica/sdk实际执行的也是lingo.dev的实现——旧包只是代理壳。版本号 0.7.17 之后不再独立演进依赖随lingo.dev0.70.4 → 0.138.5同步更新。7.2 类名层面的兼容与弃用在当前 packages/sdk/src/index.ts 中ReplexicaEngine与LingoEngine被标记为deprecated二者均继承自LingoDotDevEngine仅在构造时打印一次性弃用警告。新代码应直接使用LingoDotDevEngine。7.3 迁移步骤移除旧依赖npm uninstall replexica/sdk安装新包npm install lingo.dev安装方式见 packages/sdk/README.md替换导入语句import { ... } from replexica/sdk→import { ... } from lingo.dev/sdk替换类名ReplexicaEngine/LingoEngine→LingoDotDevEngine验证配置项apiKey、apiUrl、batchSize、idealBatchItemSize等字段语义不变可直接沿用。八、依赖安全与漏洞修复0.7.13CHANGELOG 0.7.13 记录了通过 dependency overrides 修复的漏洞清单涉及picomatch、qs、unhead/vue、postcss、ajv、launch-editor、js-yaml3.x 与 4.x 两条、joi等传递依赖。这一实践在当前仓库的 pnpm-workspace.yaml overrides 中仍可见其延续如js-yaml4 4.3.1: 4.3.1、postcss8 8.5.23: 8.5.23是 monorepo 场景下通过单一文件集中收敛依赖版本、规避npm audit报漏洞的标准做法。九、总结从replexica/sdk的 0.1.0API 抽取到 0.7.17全量代理转发至lingo.dev这条演进线清晰地展示了能力分层SDK 独立→ 能力扩展格式方法、快速模式、批量、语言识别→ 工程加固分块限流、延迟加载、漏洞修复→ 品牌与包名收敛迁移与弃用。当前仓库 packages/sdk/src/index.ts 是这一演进的最终形态也是理解lingo.dev本地化引擎调用协议的最佳源码参考——包括配置校验、locale 规范化、分块策略、指数退避重试、HTML 路径回写与成本预估等全部关键机制。对于需要深入定制的开发者建议按以下路径继续阅读源码配置 Schema 与校验 → 分块与重试 → 各本地化方法 → HTML 本地化 → 识别与预估并结合 packages/sdk/CHANGELOG.md 了解新版本的能力增量。【免费下载链接】replexicaOpen-source localization engineering tools. Connects to Lingo.dev localization engineering platform for consistent, quality translations.项目地址: https://gitcode.com/GitHub_Trending/re/replexica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考