本文深入讨论了编程术语literal的各种现有翻译及其问题，并提出了一种新的翻译建议：在一般语境下译为“文本”，在编程语言上下文中译为“源文本”。文章分析了literal与其他概念如变量和常量的区别，并解释了为什么常见的翻译如“字面量”并不准确。
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是这样处理的：
[quote]文档/文本式（document/literal-style）的SOAP绑定提供的响应更简单。[/quote]
然后加译注如下：
[quote]所谓SOAP绑定，是指服务如何转换为SOAP消息协议。wsdlsoap:binding元素上的style属性定义了绑定的风格，可以是RPC（远程过程调用）风格的，也可以是文档（document）风格的。wsdlsoap:body元素上的use属性定义了soap主体（body）的使用方式，主体中的数据可以经过编码（encoded），也可以直接使用文本（literal）。采用文档风格并且直接使用文本的，就是所谓文档/文本式（document/literal）。而清单2.14则采用了RPC/编码式（RPC/encoded）。[/quote]
对于之后的function literal，是这样处理的：
[quote]比如可以在运行时创建新的函数，可以通过不带函数名的源文本（literal） 直接创建出无名的函数对象……[/quote]
然后加译注：
[quote]源文本（literal），是指程序源代码中用来表示固定的值的符号序列。例如在大多数语言中，引号包围的字符序列即为字符串源文本（string literal），表示一个特定的字符串值。[/quote]
总的来说，我是把literal译作“文本”的，在编程语言语境下是译作“源文本”即“源代码中的文本”之意。“源代码中的文本”基本是literal的直译。这个译法的主要问题是，当然不是所有源代码中的文本都是literal。然而其英文原词本来也不可能包含这个意思，所以直译无法包括此意也是正常的。
文本一译，还与text存在冲突。但是把literal理解为text，总好过理解为var/const。而且使用“源文本”的译法，就不存在直接冲突了。虽然大家可能把“源文本”对应到“source text”上，但这至少比其它译法都接近literal的实际意思，因为literal以及其他文法符号，不过就是source text分解后的具体成份。所以string literal用“字符串源文本”来翻译，大家想到的如果是“source text of the string”，那就恰好没错了。
对于译名我有一个观点，若是一个术语有多个译名，并长期无法有一个译名占据优势，其实就暗示这些译名很可能都存在问题。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是这样处理的：
[quote]文档/文本式（document/literal-style）的SOAP绑定提供的响应更简单。[/quote]
然后加译注如下：
[quote]所谓SOAP绑定，是指服务如何转换为SOAP消息协议。wsdlsoap:binding元素上的style属性定义了绑定的风格，可以是RPC（远程过程调用）风格的，也可以是文档（document）风格的。wsdlsoap:body元素上的use属性定义了soap主体（body）的使用方式，主体中的数据可以经过编码（encoded），也可以直接使用文本（literal）。采用文档风格并且直接使用文本的，就是所谓文档/文本式（document/literal）。而清单2.14则采用了RPC/编码式（RPC/encoded）。[/quote]
对于之后的function literal，是这样处理的：
[quote]比如可以在运行时创建新的函数，可以通过不带函数名的源文本（literal） 直接创建出无名的函数对象……[/quote]
然后加译注：
[quote]源文本（literal），是指程序源代码中用来表示固定的值的符号序列。例如在大多数语言中，引号包围的字符序列即为字符串源文本（string literal），表示一个特定的字符串值。[/quote]
总的来说，我是把literal译作“文本”的，在编程语言语境下是译作“源文本”即“源代码中的文本”之意。“源代码中的文本”基本是literal的直译。这个译法的主要问题是，当然不是所有源代码中的文本都是literal。然而其英文原词本来也不可能包含这个意思，所以直译无法包括此意也是正常的。
文本一译，还与text存在冲突。但是把literal理解为text，总好过理解为var/const。而且使用“源文本”的译法，就不存在直接冲突了。虽然大家可能把“源文本”对应到“source text”上，但这至少比其它译法都接近literal的实际意思，因为literal以及其他文法符号，不过就是source text分解后的具体成份。所以string literal用“字符串源文本”来翻译，大家想到的如果是“source text of the string”，那就恰好没错了。
扫一扫
1859
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
