标签: 本地化
-
完成 A Tour of Go 西班牙语 es-ES 首次 Production 上线后,我没有停在“能上线”这一步,而是继续根据真实失败 evidence 收敛新增 locale 的生产流程。本文记录这次连续处理的 6 类问题:Cloudflare API 瞬态失败容错、首次 Production 公网验收去重、finalization 自动化、current-live locale 状态来源统一、Google/Bing 搜索引擎提交收口,以及 Locale Surface Review A gate 的 freshness scope 优化。最终目标不是让流程越来越复杂,而是让每一门新语言踩过的坑,都变成下一门语言可以直接复用的标准能力。
-
A Tour of Go 韩语翻译在 codex-ko-KR-004 中首次出现 13 个 TranslationUnit 里 3 个 validation failure。进一步排查发现,其中 concurrency/2 与 concurrency/6 并不是 Go identifier 真正丢失,而是韩语助词直接附着在 ASCII 标识符后,触发了 validator 的词法边界误判;concurrency/4 则属于真实的 present font span 结构错误。本文记录如何区分“应该改译文”与“应该改 validator”,并通过 ko-KR 窄规则、正反测试与 revalidate 流程,将结果从 10/13 提升到 12/13,最后再修正真实 candidate 问题达到 13/13。核心原则是:validator 的目标应保护技术身份,而不是强迫目标语言适应源语言的书写边界。
-
A Tour of Go 韩语版原本预计约 6 小时完成,但最终从初始化到 production 收尾跨越约 44 小时。根据 76 次 Git 提交按 30 分钟封顶方式估算,实际活跃投入约 15 小时 43 分,结合 ChatGPT、Codex、浏览器、服务器、Cloudflare 和 Naver 等未完整进入 Git 的操作,最终更适合记作约 16~18 小时。本文复盘韩语为什么明显慢于法语:包括多轮 Quality Check 与 revision、Final Review 后再次返工、韩语语法触发新的 validator 边界、5 小时模型额度影响生产节奏,以及 TranslationUnit 完成后仍持续出现的 preview、production、Cloudflare、课程目录和 Naver 上线问题。最终也重新认识到,成熟流程的价值并不是保证每门语言都越来越快,而是遇到真实问题时,能够正确地慢下来并留下可复用的改进。
-
A Tour of Go 法语版在约 9 小时内完成上线后,我没有立即开始下一门韩语,而是先继续完善新增 locale 的执行流程。这一轮优化不再重复讨论“如何建立一套标准流程”,而是进一步减少已经可以机械化的重复操作:新增 locale init 初始化能力、自动生成语言骨架与状态文件、完善首次 production 自动化与 production identity、精简命令执行成本,并建立 Deferred Issues 机制记录已经真实发现但暂缓处理的问题。目标不是减少 Quality Check、Final Review 或 production acceptance 等质量 gate,而是把人的时间更多留给真正需要判断的翻译质量和生产风险。
-
A Tour of Go 第三门社区语言 de-DE 已正式上线。从开始推进到完成 TranslationUnit 质量审核、Locale Surface Review、production 部署和最终验收,这一轮粗略投入约 16 小时。 但这 16 小时并不是从零开始完成一门语言的全部成本,而是建立在此前数百小时的项目开发、质量流程、服务器基础设施和第二门语言标准化工作之上的增量成本。de-DE 真正值得复盘的,是第三次完整执行以后又暴露出了哪些历史流程债、哪些人工操作已经可以交给工具,以及为什么下一门语言的目标可以进一步压缩到 8 小时以内。
-
在 Laravel 6 和 Lighthouse 5 环境下,使用 @rules 指令应用 exists 验证规则时,自定义属性名无法按语言区域正确翻译,导致返回的验证消息中包含原始字段名而非本地化名称。经过排查,排除了 nwidart/laravel-modules 版本及语言文件位置的影响,确认原因在于 Lighthouse 5 对验证属性的支持不够彻底。目前决定暂不编写自定义验证器类,暂时接受在非英语环境下属性名未被完全翻译的现状。
