分类： IT社区
-
在 A Tour of Go 意大利语站点上线后，我重新整理了 Google Search Console 与 Bing Webmaster Tools 的搜索引擎收口流程。Google 侧完成站点验证并提交 sitemap.xml 后，Bing 可以复用已有的 Google Search Console 账号授权，通过手动 Import 快速导入新的 locale 站点及 sitemap。本文记录 it-IT 从 GSC 成功发现 105 个页面，到 Bing 导入站点并识别 105 个 URL、0 错误、0 警告的完整过程，并明确“账号连接可复用，但新站点仍需手动导入”的边界。
-
在 A Tour of Go 意大利语站首次 Production 中，Machine Acceptance 已经通过，但 Headless Chrome 却连续在 / 和 /tour/ 报出 page did not render。进一步排查发现，同一台 ThinkPad 对这两个页面连续 20 次 curl 请求全部返回 HTTP 200，问题并不在普通公网访问，而在 browser acceptance 对 document.readyState == “complete” 的依赖过强。最终将 render readiness 调整为 interactive 或 complete 加有效 body 内容，并允许最多 3 次独立 navigation，同时继续让正式语义检查保持单次、fail closed。修改后 Production Browser Acceptance 顺利通过。
-
在 A Tour of Go 意大利语站首次 Production 过程中，站点部署、源站和 Cloudflare DNS 都正常，但公网验收却连续遭遇 curl 28、curl 97 等网络瞬态失败。最终没有继续堆叠更复杂的 SOCKS、超时和重试逻辑，而是把正式公网 machine acceptance 直接迁到 zgocloud 执行，让 105 个 sitemap URL、CDN Cache、HTML Identity 和 Socket Boundary 等检查稳定通过。本文记录这次从跨境 SOCKS 链路到 zgocloud direct 的调整过程，以及 bounded retry、fail closed、保留 Production 现场并正式 resume 等实践经验。
-
完成 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 的社区翻译历史中，法语、德语、韩语等多个项目都曾长期维护、积累大量提交，却最终出现仓库归档、站点离线，甚至原仓库不可访问的情况。本文结合官方 tracking issue 与多语言仓库 Git 历史，分析社区翻译真正困难的并不是第一次上线，而是多年以后仍然能够持续同步上游、维护部署、掌握 production 权限，并承担服务器、带宽、CDN、域名、AI 工具和维护时间等长期成本。也正因为如此，我现在不仅重视统一流程、正式文档和自动化，也开始通过广告尝试让多语言项目逐渐具备一定的自我供血能力，降低长期完全依赖个人时间、热情和资金补贴的风险。
-
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 小时以内。
-
此前 A Tour of Go 课程页手动 AdSense 广告一直使用 Responsive，并曾通过 max-width: 620px 限制广告容器宽度。当时我在自己的 production 人工测试中，经常看到较小的正方形广告，点击“下一页”后也很容易继续出现广告，体感上的展示概率甚至超过 90%。后来为了充分利用桌面端剩余空间，并尝试获得更宽、可能价值更高的广告，我删除了 620px 最大宽度限制。结果却出现了一个很明显的变化：人工测试中实际看到广告的频率大幅下降，体感甚至不到 5%。由于这些只是发布者自己的有限测试，不能直接作为正式填充率结论，我最终没有简单恢复 620px，而是建立 A/B/C/D 四个独立 Responsive AdSense 广告单元，分别测试 336px、468px、728px 和不限制宽度四种方案，各分配 25% 自然流量，并在同一浏览器标签页中保持稳定分组。目前实验已经正式上线，接下来将停止主动测试，让真实自然流量回答不同广告位宽度究竟如何影响展示量和收益。