加载失败
讨论源自一篇短博文，作者以 UI 文案（例如“Uploading 1 item(s)”）表达想加入重视工艺的公司的愿望。评论分成两条主线：一方面把界面小处视为工匠精神与信任的信号，另一方面将其视为资源优先级问题，主张先保证功能、性能与可访问性再做润色。技术讨论深入到国际化（i18n）的细节，评论举出波兰语、乌克兰语等多种复数规则，并引用 Qt、Mozilla Fluent、Unicode CLDR、Locale::Maketext、npm pluralize 等现成工具与实践。也有人把把细节当道德试金石的做法比作“Californian Ideology”（加州意识形态批评）或用 Van Halen 的 brown M&M 条款类比，指出商业模式与工程激励往往比语法更能决定用户体验的好坏。
许多评论认为界面中的微小用词和排版是公司是否重视产品工艺的信号，像“Uploading 1 item(s)” 这类懒惰写法会让用户感到产品冷漠无心。支持者用“破窗/千纸钉割伤”类比、学校赠送 Blackwing 铅笔的例子和“say-mean-do”规则来说明小处反映长期态度，认为细节累积会影响用户信任和品牌感知。他们还强调这是跨职能问题，不只是工程的事，文案、设计和 QA 都要参与，招聘到愿意在细节上下功夫的人很罕见但价值巨大。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
另一类评论强调这是资源和优先级问题：在有限时间和预算下，应先保证核心功能、性能和可访问性，再去抛光文字表述。有人指出与其为复数做复杂逻辑，不如先修复更关键的可访问性问题（如屏幕阅读器、高对比、键盘导航）或性能瓶颈；如果复数处理破坏了核心路径，那说明工程上有更严重的问题。实践中常见折衷包括把数字与描述分离、改写文本以避开复数分支，或把复数处理列为低优先级以保住交付节奏。
大量技术回复把讨论拉回到 i18n 的现实复杂性：很多语言的复数规则远超英文的单数/复数二分，例如波兰语、乌克兰语等会根据末位数字和词形变化出多种形式，甚至存在双数（dual）、paucal 等范畴。基于这些实际情况，评论里推荐使用成熟的本地化方案与库（如 Qt 的 plural 支持、Mozilla Fluent、Unicode 的 CLDR 复数规则、Perl 的 Locale::Maketext、npm 的 pluralize），或者在字符串层面用翻译 token/占位符把数字与语句分离，交给翻译/本地化流程处理。也有具体实现示例（如作者贴出的 token 列表、GridWhale 的 String 处理函数）和工具引用，说明正确做法比简单“(s)”更稳健但需要额外时间与技能。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
另一批评论反对把语法或微观界面细节上升为公司是否“善良”或“值得加入”的道德测试，认为这种类比带有典型的“Californian Ideology”式天真。有人用 Van Halen 的 brown M&M 条款做对照，指出表面细节可能只是合同或流程检查的信号，但不能替代对商业模式、激励结构（如广告驱动）和工程决策的深入审视。评论里还警告，强调“贴心个性化体验”可能被滥用为更有害的个性化广告或算法优化的正当化，单凭文案精致与否无法证明公司价值观。
i18n: i18n（internationalization 的缩写）：指为软件支持多语言与区域惯例所做的工程实践，涵盖文本翻译、复数规则、日期/数字格式化等问题。
CLDR: CLDR（Unicode Common Locale Data Repository）：Unicode 提供的本地化数据仓库，包含各语言的复数类别、格式规则等，很多 i18n 框架以其规则为依据。
Fluent: Fluent（Mozilla 的本地化框架/格式）：一种支持上下文、复数组选择和词序重排的翻译格式，便于为复杂语言场景编写可被本地化团队正确翻译的字符串。
brown M&M 条款: Brown M&M（Van Halen 的合同条款）：演出合同里要求移除棕色 M&M 的条目，常被用作检查场地方是否认真阅读合同的“金丝雀”或表面检验例子。
双数/复数范畴（dual / paucal）: 一些语言有超过英语的单/复二分法，例如 dual（双数）、paucal（少数）等复数范畴，使得简单的 one/other 逻辑无法覆盖所有语种的复数规则。