新一篇: 版本、兼容性以及标准 | 旧一篇: 谈Intranet、Internet诸词的译名：内联网、互联网、因特网等等

本文原发于我在JavaEye上的技术部落格，备份于此。

---

literal这个词很讨厌，现有的译法众多，但都问题多多，而且没有一种占据绝对优势。如文字量、直接量、常量、常值、字面量、字面值、实字等等，也有直接译作“文本”，或者保留英文不译，或者通过采取基本等价的意译来规避的。

对于译名我有一个观点，若是一个术语有多个译名，并长期无法有一个译名占据优势，其实就暗示这些译名很可能都存在问题。literal不幸也是如此。

首先literal不是constant，所以不好用“常量”来翻译——虽然乍一看它很像“常量”。尽管如此，还是有一种看法，认为 literal和常量、变量的差别只是赋值的时机，前者是在编译时，而后者是在运行时。根据这种看法，就有若干种“XX量”的译法，典型的如“字面量”、 “直接量”。

然而这种看法值得质疑。问题不在于何时赋值，而是literal根本没有赋值的概念。因为赋值（还有变量、常量）是语义上的概念，而literal完全不是语义层面的东西。

所以literal不太好译作“xx量”。“XX量”除了变量、常量外，就是如标量（scalar）或向量（vector），都是指具有某种计算性质，也是语义层面的概念。而literal没有这种含义。

也有人将其译作“xx值”，例如常值或字面值。这比“XX量”要好，但是literal其实也不是值，而是值的符号表达——也就是literal始终是文法层面的概念。

这从各种语言规范里可以看出来。

Java的语言规范，literal是在lexical一章。也就是，它和Token、Line Terminators还有Comments是一个层面的。

Python的语言规范，literal是在Lexical analysis一章中，与它并列的是Line Structure、Identifiers and keywords以及Operators等。

再如ECMAScript规范，literal也是在lexical conversions一章中的。

我们看看和literal并列的，其实都是文法中的某种符号或token，譬如标识符、运算符、分隔符、关键字、分隔符、空白符、终止符……乃至Unicode字符序列。因此，翻作“XX量”或“XX值”都是文不对题的。

其实我本来考虑过是否可翻成“值符”或“常值符”的。类似的，台湾除了“常值”的译法最为常见外，还存在一些译法，如“实字”和“定字”（葉秉哲 译法），其与“值符”的译法有相通处。但考虑再三，我觉得引入这样的新译法可能过于突兀，而且也存在一个问题——“值”通常会让人觉得是数值—— string literal若作“字符串值符”或许还容易理解的，function literal作“函数值符”就晦涩了，所以还是退而求其次，我倾向于选用已有的译法“文本”和稍作改造的“源文本”。

在目前我正在翻译的一书中，对literal就采取了这一译法。

其中对于soap的document/literal-style是这样处理的：



然后加译注如下：



对于之后的function literal，是这样处理的：



然后加译注：



总的来说，我是把literal译作“文本”的，在编程语言语境下是译作“源文本”即“源代码中的文本”之意。“源代码中的文本”基本是 literal的直译。这个译法的主要问题是，当然不是所有源代码中的文本都是literal。然而其英文原词本来也不可能包含这个意思，所以直译无法包 括此意也是正常的。

文本一译，还与text存在冲突。但是把literal理解为text，总好过理解为var/const。而且使用“源文本”的译法，就不存在直 接冲突了。虽然大家可能把“源文本”对应到“source text”上，但这至少比其它译法都接近literal的实际意思，因为literal以及其他文法符号，不过就是source text分解后的具体成份。所以string literal用“字符串源文本”来翻译，大家想到的如果是“source text of the string”，那就恰好没错了。 

发表于 @ 2008年02月08日 21:52:00|评论(loading...)|编辑

新一篇: 版本、兼容性以及标准 | 旧一篇: 谈Intranet、Internet诸词的译名：内联网、互联网、因特网等等