关于 “selector” 一词的译法

[cssmagic]

@hax 问道：

用“选择符”而不是“选择器”有什么讲究吗？

我本人倾向于将 JavaScript/jQuery 中的 querySelector/selector 译作 “选择器”，而将 CSS 中的 selector 译作 “选择符”。

我本人倾向于将 JavaScript/jQuery 中通过 CSS selector 匹配查找元素的 .querySelector()/.query()/$() 函数译作 “选择器”，而将 CSS selector 译作 “选择符”。

原因在于，前者的工作方式是主动获取，将其视为工具；而后者的工作方式是被动匹配，将其视为一种描述符号。

---

本讨论源自：#1 (comment)

[cssmagic]

@hax 评论：

主动和被动并没有啥差异啊，为啥要用不同的术语。。。

[Justineo]

我参与讨论的语境下，都是使用的「选择器」。

HTML 中文兴趣小组翻译的 CSS2 规范中也是使用的「选择器」。

[yisibl]

CSS 「选择器」 比较普适，参见：http://yisibl.github.io/css-vocabulary/

[Justineo]

再加一点今天想到的：英语中动词 + er/or 本身就表示施加动作的人吧？所以 selector 在英语中似乎也应该是一个主动的关系？

[yanxyz]

我以前都是用”选择符“，因为最开始接触的就是这个。另外确实有一定的道理，它们是像通配符的一样的符号。后来看”选择器“多了，也转向”选择器“。

我觉得你那样的细分理由并不充足，又增加了负担，用我们的行话说，没有为用户考虑。

二者究竟选哪个？我实际上倾向于 ”选择符“。

[hax]

我不推荐“选择符”，是因为selectors不是简单的“符号”，而是本身有结构的DSL。

关于主动与否，我同意@Justineo ，selector一词本身就是主动的。querySelector按照道理应该是queryBySelectors，只是为了简化api才是现在的名字。

[cssmagic]

@Justineo：HTML 中文兴趣小组翻译的 CSS2 规范中也是使用的「选择器」。

这个页面光是目录就错误连篇（“子代择器”、“before和after伪类”等等），我就暂时无视了吧……

[cssmagic]

谢谢大家的评论，我来说一下我的想法。

“选择器”

直译

诚然，它最普遍的译法，普遍到了轶灵兄 (@Justineo) 所提到的这种程度：

我参与讨论的语境下，都是使用的「选择器」。

它为何如此普遍？因为它是直译，而直译是最安全的。不论它是否是最贴切、最形象的，但只要是知道英文原文 “selector” 的人，看到这个译法都可以不加思索地映射过去——是为 “安全”。这是它最大的优点。

而我为什么不喜欢它呢？因为直译是最不需要动脑筋的译法。很多术语，由于最初译者的不动脑筋（或是根本没理解原意吧），结果让不那么贴切、甚至是有误导性的直译流传开来。比如滑动门（sliding door），比如浮动（float）。

“选择器”，完全中立，直接对应原文，没有任何为便于理解而添加的辅助信息。这当然没有错，但效果就不一定是最佳的了，因为存在理论上可能的提升空间。

有一些术语，最开始普及开的可能是直译，但经过译者和读者长时间的理性选择之后，最终流行的并不是直译。比如 timeline（这里特指动画或历史的时间推进方向），有译 “时间线”，但胜出者是 “时间轴”。相对于安全而平直的 “时间线” 译法，“时间轴” 提供了更多的信息；或者说，它把原文中平实中立的宽泛信息（“线”）替换为更利于理解的具体信息（“轴”）。后者是一个经过思考的翻译，而不是机械的转换。

歧义

另外，“选择器” 一词在前端开发中文圈内可能存在歧义（多种解读）：有相当多的人把 jQuery 的 $() 函数称作选择器，诸如 “jQuery 的选择器很好用”、“jQuery 的 DOM API 把选择器作为入口” 这样的表述（大家可以搜一下 “jQuery 选择器” 这样的关键字）。这可能是以讹传讹，也可能就是中文读者和中文作者的自发选择——“选择器” 一听就是用来（从 DOM 树中）选择元素的，它是一个实施动作的主体。

贺老 (@hax) 认为 “selector 一词在 JavaScript/jQuery 和 CSS 中所指的是同一件事，应当使用相同的译法”——前半句我是认同的，英文语境下确实是指同一件事物。但显然广大人民群众在中文语境下的自然选择不是这样的。很多人在写 jQuery 教程时用到了 “选择器字符串” 这个词，你可以猜到它指的是什么、以及同一篇文章当中的 “选择器” 指的又是什么。

鉴于这种歧义普遍存在，我主张：

我本人倾向于将 JavaScript/jQuery 中通过 CSS selector 匹配查找元素的 .querySelector()/.query()/$() 函数称作 “选择器”，而将 CSS selector 译作 “选择符”。

这个想法以贺老的观点来看，在理论上显然是 “不完美” 的，但我自认为是一种务实的做法。

“选择符”

出处

我最早接触的译法应该是 “选择器”，毕竟它流传最广嘛。而最早看到 “选择符” 这个译法应该是在某本不错的 CSS 书籍中。我记忆中以为是《CSS 权威指南》，但实际上后来发现我记错了，真正的出处应该是《CSS 实战手册》或《CSS 实战精粹》或类似的教程书。

该书的译者特意在译注中解释了为什么采用 “选择符” 这个译法，而不是 “选择器”。大体的意思就是 selector 是便于匹配元素而设计的描述符，用 “选择符” 这个译法更精确。

我对此印象深刻，而且十分赞同，从此以它为准。（其实对我来说，完全不存在痛苦的转换过程，因为这一堆书都是我在初学 CSS 时几乎同时看完的。甚至可以认为这个译法对我来说就是先入为主的。）

优点

跟 “时间线 vs 时间轴” 类似，这个译法在中立的宽泛信息（“器”）之上增加了更利于理解的具体信息（“符”）。这样做可能是危险的，但如果得当，将是更加贴切的。

缺点

首先，不够流行。跟 “选择器” 相比，这个译法在互联网上的使用数量存在明显差距（38,300 vs 250,000）。但流行度又能说明什么呢？我假设我们是在讨论译法的优劣，而不是使用率的多寡。而且这个差异还真没有我想像的那么大。

接下来的质疑，就在于 “符” 这个字了。比如贺老是这样说的：

我不推荐“选择符”，是因为selectors不是简单的“符号”，而是本身有结构的DSL。

如果是叫 “选择式”，我觉得还更有说服力一些。

乍一听很有道理，我甚至动摇了。但当我清醒之后，我发现自己不过是又一次受到了贺老的现实扭曲力场的影响。在我们每天都挂在嘴边的一些技术术语中，有很多 “符” 都不是常规概念上的 “符号” 或单个字符：

• 标识符（identifier）：往往是由字母、数字等构成的字符串。
• 描述符（descriptor）：CSS 的 @font-face 规则中的 unicode-range 就是一个描述符。
• 统一资源定位符（URL, Universal Resource Locator）：各种字母、数字、标点符号所构成的复杂语法，简直不能更乱。
• 占位符（placeholder）：UI 的中的占位符可能是任意对象——文本、图片、控件等等。

还有其它缺点吗？

我（目前）的选择

虽然经历了短暂的动摇（尤其是在收到我的偶像 @Justineo 和我的导师 @hax 的反对意见之后，以及当我发现《CSS 权威指南》和《精通 CSS》所采用的都是前者时），但随着翻译进程的推进，我越来越相信 “选择符” 是一个更好的选择。

这是一本近十年来最重要的 CSS 图书，没有之一。十年前的译法就让它随风而去吧。

当然，这是我目前的选择；而在付印之前，一切皆有可能。我仍然期待更好的反对意见，我仍然期待被说服。

[yanxyz]

:-)

[hax]

我仅就“符”的几个例子讲下我的意见：

• identifier 可以有结构，但本身是opaque的
• url 尽管有结构，但如作为uri意义上使用时本身是opaque的，仅在需要dereference或resolve时需要考虑结构
• placeholder 可视为特殊的 identifier

以上三者实际上均为identifier，和selector都有比较显著的区别，就在于其本身是opaque的，所谓opaque，即在主要使用场景下是完全不考虑内部结构的，可视作纯粹的“符”号。selector如果有什么使用场景是不考虑内部结构的，那也是jQuery的场景（即和你现在的分立是相反的）。

关于URL

url确实有使用场景需要考虑结构。然而url也有“定位器”的译法（见维基百科词条），google搜索两种译法在一个数量级（3万和2万条）。且以我看法，确实更推荐“定位器”和“标识符”的分立。只是今天whatwg的规范将uri和url合一了，这是术语本身的演化。而且现在whatwg的规范里根本不提 locator，对url的定义是“universal identifier”（如翻译，则为“统一标识符”），而不再使用缩写定义，即实际统一在uri的意思，但用了url的名字。

descriptor

这个问题就比较复杂了。

首先，此词在CSS规范的场景下，我称之为“弱术语”。所谓“弱术语”就是并非有spec给出明确定义的技术词汇，它本质上只是一个普通词汇，以一种符合spec写法的，以比较严谨和一致的方式使用而已。比如css property也是一个弱术语。

那么考虑descriptor本身，其意思其实是，用来描述和指示某些东西的那么个玩意儿。所以descriptor是一个本身有很大弹性的词（参见https://en.wikipedia.org/wiki/Descriptor ），比如搜索关键词也可以叫“descriptor”。

编程术语里，“descriptor”通常是有结构的，比如js里的property descriptor，包含了3个特征。python的descriptor也是类似的。所以“描述符”的译法在这个场合下（按照我的观点）是不对的。property descriptor根本不是符号，而是（描述特征的）数据。js中的pd确实被翻译为“描述符”，但是更多人是不翻的（包括我），我自己觉得以及我猜许多人直觉也是如此——“描述符”的译法反而增加了理解困难。

但是为什么我们常见“描述符”的译法？恐怕是来自于Unix操作系统的“file descriptor”（文件描述符）以及类似的process descriptor、socket descriptor等。它的形式为整数，实际是表索引（指针），符合前述的opaque的特征，译为“描述符”倒也还行。不过这仅限于Unix中的这个特定语境。一旦用到了别的场合，就会造成理解困难。

另外即使英文术语本身而言，descriptor也不如handle（句柄）好。注意我是说概念理解上，但你不能换成handle，因为两者在细节上是不一样的。

所以“file descriptor”在本来场合（我认为）就不是一个最佳术语，因为它和descriptor的其他用法不太一样。而把file descriptor的译名用到其他descriptor就很糟糕了。这种问题其实在译名也屡见不鲜，比如frame的译名帧/框架之混乱。

descriptor本身比较好的直译译名或许是“描述子”或“描述元”（大陆常见xx子，台湾常见xx元）。当然，如能根据具体场合，将“子/元”换为带有更多信息的字（器/符/式等），自然是极好的。不过绝大多数人也就随手搬运，根本不会想那么多，那还不如老老实实用“子/元”的译法。

回到CSS规范的场景下，我也不建议用“描述符”来翻译。因为显见它并非identifier。实际上，css descriptor和css property几乎是一样的（在句法层面根本不区分），只不过property用于qualified rules（即selectors { ... }），而descriptor用于at rules（即@xxx { ... }里）。如分别用“属性”和“描述符”来翻译，完全不对等。不过这里的descriptor到底用什么译法好，我也暂时没有想好。

[cncuckoo]

中国古代有“合符”这个词，就是匹配的意思：http://baike.baidu.com/view/1172082.htm :)

[zilong-thu]

投票给CSS“选择符”。以表明它的确只是描述性质的匹配符，而不是执行某些操作的工具（器具）。窃以为，译者是应当具有 CSSMagic 老师这样的使命感的。