2023 多语言规范调整

背景

大概在 2020 年的时候，hido 整合了多语言合规性校验，除了语言校验工具；结合了语言规范，对于语言的使用做了一些限制，比如：前缀限制，后缀限制等。迫使前端研发新增了不少工作量和心智负担，具体内容可以看下我这篇文章 Vessel 多语言合规性问题汇总。

经过2年多的交涉，在本月的统一软件技术架构会上，有了一些进展。还是先说下结论：

1）对多语言后缀定义进行完善，新增 other 后缀，试点验证通过后纳入规范，规范工具试点中，预计规范Q3修订，10月份发布
2）国际化规范编制组定期对多语言key的定义进行梳理，提炼通用key，并提供开放接口供研发使用，用于研发提效。Q3季度末可以进行开放接口的调试，调试前会给出接口文档。
3）前端技术组牵头组织培训，加强前端同事对于国际化规范的理解。培训在和移动端、客户端拉通一下。预计9月份安排培训，主要面向校招新人及对规范理解不清楚的前端、移动端、客户端同事

最早的规范：

但问题是这个命名其实非常不合理，name 一般通常指名词；这点对于不懂规范的人来说理解起来有一层心智负担；

而中国名词博大精深，形容词，动词，感叹词，介词，量词等，都无法被上述词语所覆盖，所以这次新加了一个后缀 other，用于覆盖上述的情况。

WARNING

但要注意，不要全部都用后缀 other，规范只是在试运行阶段，如果后续大部分都存在滥用可能还是会把规范给废弃掉。

其实我当时不继续维护 easy-tool 的原因之一，就是想推动国际化规范组的同事，把通用 key 给提炼出来，然后提供给研发使用，这样可以提高研发的效率。

后续应该在Q3的时候，他们会提供对应的接口，来生成通用 key；到时候我们可以制作类似的 vscode 插件，来辅助我们的开发。

其实我们有很多这样的场景，组件 A 使用了视频播放，整块功能会迁移到组件 B，但是因为前缀的事情，这些多语言 key 都要再改一遍前缀。如果有了通用 key，我们就可以直接复用了。

其实规范组有答应我说在校验工具中把组件标识（前缀）去掉，但我自己也没验证过（有验证过的同学可以私聊我一下），但移除前缀的事情他们不会写进规范，最终解释权还在他们手中。但我个人是觉得，前缀的事情真的没啥必要。

2020 年版本的多语言，之前是未经大部分前端评审就制定的；规范制定人只是通知了部分部门的负责人。所以，对于后缀以及工具的事情我们也是后知后觉。这块其实问题最为严重，我也和规范负责人 陈钦 工对了下，后续规范的指定必须经过前端技术组的评审，这样才能保证规范的合理性。

公司对于规范的宣贯做的一直不是很到位，但其实我沟通下来规范组也是愿意做培训的，这块我想等今年校招新人入职以后一起培训掉，时间大概在9月份。

本次规范推进的过程时间比较长，2021年推进的时候比较困难；但到2023年推进的时候就相对顺利点，可能跟我找的人有一定的关系。

本文最主要的目的是通知大家，规范新增了一个后缀 other，用于覆盖之前的一些不满足的情况；