|
|
发表于 2003-12-29 10:25:15
|
显示全部楼层
..
BABELCODE 方案简介
创作可机器翻译的内容
http://www.babelcode.org
姚子渊 (info@babelcode.org)
复旦大学计算机系本科一年级生
2003 年 12 月 13 日
目录
概览与演示
作者与读者预备条件
翻译流程
集成创作环境与源脚本语言
创作概览
解析式构建 (自由发挥)
使用宏 (固定的模板)
巴别代码 (BabelCode): 为可机器翻译内容设计的编译格式
词典
翻译引擎
概览与演示
目前机器翻译和计算机辅助翻译的理论和实践存在严重问题：
l 分析型与统计型机器翻译方式产出令人误解和不舒服的结果，主要归因于完美的歧义剔除是不可能的。所以它们对于行业级强度的应用是不合格且不可靠的。
l 计算机辅助翻译牵涉到真人翻译员并且对多语言译本需要额外的努力，造成巨大的费用、时间和真人翻译失误的风险。
在 BabelCode 方案里，我提出一系列的方法，它们可以使作者能直接创建可机器翻译的内容，并保证翻译的正确性、有效性和可读性，外加一个好处：你可以自动由单个源文件得到多语言译本。
在这里你可以检视模拟使用我的系统得到的翻译样例：
1. Oh, say can you see by the dawn's early light
What so proudly we hailed at the twilight's last gleaming?
哦，看，你可以借助拂晓初期的光，看见我们如此骄傲地、向黎明最后的泛动致敬过什么吗?
2. 更多的例子将在这里补充…
作者与读者预备条件
要求作者掌握他的母语（读和写）、基本语法分析能力和一种源脚本语言。不要求他掌握任何外语。
要求读者掌握他的母语（读）。不要求他掌握任何外语。
翻译流程
想写什么
(1. 作者、IAE 和词典) à
源脚本文件
(2. IAE) à
BabelCode 文件
(3. 翻译引擎和词典) à
为读者准备的目标语言版本
关于这三个过程的注释：
(1) 作者通过一个集成创作环境 (IAE) 和一个或多个词典，创建一个源脚本文件。
(2) IAE 自动把源脚本转换成一个 BabelCode 标准格式文件。
(3) 某个翻译引擎 (TE) 根据这个 BabelCode 文件以及它用到的词典，翻译出需要的目标语言版本。
如你所见，人工干预仅仅在创作过程（第 1 步）中涉及。
参见这些涉及到的关键部件: IAE, 词典, 源脚本, BabelCode, 和 翻译引擎.
集成创作环境与源脚本语言
集成创作环境 (IAE) 和源脚本语言是直接跟作者打交道的用户接口（界面）。
IAE 是一个提供作者编写源脚本的环境的软件程序。IAE 还能自动把源脚本转换成 BabelCode 文件。
源脚本并不是一种单一格式，而是对任何作者用来表达意念的用户脚本语言的通称。而 BabelCode 是一个编译后的、被所有翻译引擎识别的标准格式。源脚本和 BabelCode 的关系好比 Pascal / C 源文件和机器码的关系 – 可能存在很多用户编程语言 (Pascal, C, C++, BASIC) 并且它们被不同的用户所偏爱，但是只存在一种标准的编译文件格式 (机器码)。同样，可以存在许多种源脚本：汉语脚本、法语脚本、德语脚本等等，但 BabelCode 是翻译引擎识别的唯一的标准编译格式。
创作概览
句子是正文的基本表达单元。作者有三种方法写一个句子：(1) 解析式构建；(2) 使用宏；(3) 混合使用以上两种方法。
选择哪种方法的一般性原则是：
(1) 如果可能，总是使用宏；
(2) 在 IAE 和我们建议的用法下使用解析式构建。
解析式构建
解析式构建可以解决语法、词义和指代等二义性。在这种模式下，作者像书写一个数学算式一样写一个句子。这个句子含有一些符号和各种括号，用来指示该句子的详细语法结构。如果遇到多义词，这些符号还能指示作者希望用这个多义词表达的那个意思。
例如，某种源脚本的代码这样写道：
我 是 一只 (伶俐的:聪明> 猫。
“(“ 和 “>” 标出一个修饰语“伶俐的”。该修饰语修饰右边的“猫”（“(..>”表示“修饰右边的成分”，而“<…)”表示“修饰左边的成分”）。因为“伶俐的”是一个多义词（1. 聪明; 2. 轻巧; 3. 爽快; 4. 正当），我们再用一个索引关键字“聪明”来钉死我们想表达的那种词义。当编辑这个句子的时候，IAE 可以提供“句法色彩高亮”，将浅色赋给索引关键字和辅助符号，将深色赋给“正规文本”，诸如“伶俐的”和“猫”。IAE 还可以提供“就地下拉菜单”来及时提示作者一些可用的索引关键字或接下来可以使用语法结构，就像Visual C++ 集成开发环境里的智能感知 (IntelliSense) 那样。
当 IAE 把源脚本转换成 BabelCode 时，所有的功能性符号 (“(…>”, “:”, 等等) 和结构将被转换成标准形式。我将在“巴别代码 (BabelCode): 为可机器翻译内容设计的编译格式”这一节描述这种标准形式。
使用宏
宏帮助作者摆脱复杂和不明确的语法分析并避免表达中的文化与文化之间的差异。作者要做的仅仅是选择一个宏，然后“填空”——填写这个宏需要的参数。例如，某个宏的原型可能像这段伪代码所示：
谓语 胜过 (名词短语 胜过谁, 名词短语 在哪方面);
那么如果作者想说“我在跑步上胜过汤姆”，他可以通过在他的源脚本中调用以上宏来达到目的：
我 胜过 (汤姆, 跑步);
如你所见，宏将代替作者来处理内部语法结构的细节问题，甚至还能自主选择附加的单词（在这个例子里是一个介词“在…上”）。这个特性在“逐词翻译”无能为力的时候尤其重要。汉语使用“在某方面上胜过某人”，可是英语且使用“在某方面中胜过某人”。如果没有宏，一个汉语作者将导致介词“在…上”混进最终的英语译本。而如果有了宏，宏就能帮助作者打理一切，因为对于每一种目标语言，宏都有不同的内部实现，如以下伪代码所示：
谓语 胜过 (名词短语 胜过谁, 名词短语 在哪方面); 汉语;
{
在 “在哪方面” 上胜过 “胜过谁”;
}
谓语 胜过 (名词短语 胜过谁, 名词短语 在哪方面); 英语;
{
be {
_superior(good:fine)
<than:prep “胜过谁”) &
<in:about “在哪方面”);
}
}
上面在 { } 中的代码即这个宏的内部细节的解析式构建（实际上可以更简单）。你可以想象到，既然作者能使用解析式构建，他必然也能建立他自己的宏。
实际应用中的宏能发挥比以上例子更大的威力，因为它们完全可以封装一个更生动自然的目标语言表达方式，而不是一个生硬的逐词直译。
巴别代码 (BabelCode): 为可机器翻译内容设计的编译格式
“BabelCode 格式规范”定义了标准的、面向机器的格式用来记录解析式构建与宏调用（统称“可机器翻译的内容”），外加一些装饰性和注释性元素。所有的翻译引擎 (TE) 必须识别 BabelCode 格式的文件并且基于这种信息来构造出各种目标语言的译本。但设计 BabelCode 的目的不包括让作者直接查看或编辑这些 BabelCode 文件的内容。
你可以在附件“babelspec”中查看 BabelCode 格式规范。
词典
词典有两种作用：
(1) 为每个多义词或多义宏提供一个意义列表，让作者可以从中选择他意图的那个意义。
(2) 为每个意义或宏提供翻译候选 (translation candidates) 以及附加信息，让翻译引擎可以根据这些“自解释 (self-explanatory)”信息来构造出一个目标语言译本。
一个源脚本/ BabelCode 文档可以指定一个或多个词典作为解释用途。这就像你在一个 C 语言源程序里包含了若干头文件一样：
#include <stdio.h>
#include <stdlib.h>
// 这里开始代码.
类似的我们可以有：
#include <general.dict>
#include <computer_science.dict>
// 这里开始 BabelCode 代码.
如你所见，作者可以指定一个通用词典和一个计算机科学领域的专业词典。
你可以在附件“dictspec”中查看词典格式规范。
翻译引擎
翻译引擎 (TE) 是接受 BabelCode 文件然后输出某种目标语言译本的软件程序。翻译引擎也可以被集成到 IAE、互联网浏览器、即时聊天客户端程序等等中。
除了输出一个翻译结果，一个翻译引擎可能还会在翻译结果上加上一段“读者须知”用来告知读者在翻译过程中由于一些不可避免的文化差异导致的注意事项。
得益于 BabelCode 和词典的格式设计，开发一个翻译引擎仅仅是编程的事。在这里没什么重大的技术考量需要讨论。 |
|
IP卡
狗仔卡
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主