VNR共享辞书中翻译的转码和代理

发布时间：2020-12-14 01:14:06 所属栏目：百科来源：网络整理

导读：源地址： http://sakuradite.com/topic/724 优先进入官网看，官网不行再观看本文坏掉的功能由于共享辞书的变更，部分以前的功能变得不那么好用了。 [[N]]重命名为[[m]] 在前缀、后缀中使用的[[N]]，现在改为用[[m]]了。带来不便很抱歉！边界+姓名+后缀当

源地址：http://sakuradite.com/topic/724

优先进入官网看，官网不行再观看本文

坏掉的功能

由于共享辞书的变更，部分以前的功能变得不那么好用了。

[[N]]重命名为[[m]]

在前缀、后缀中使用的[[N]]，现在改为用[[m]]了。带来不便很抱歉！

边界+姓名+后缀

当姓名打开边界后，将可能无法正常的与后缀匹配。
比如，如果定义了两个词条：
姓名：悠真=>悠真

后缀：兄=>哥哥
那么一旦对姓名或者后缀打开词条边界的选项，那么VNR将不能在翻译"悠真兄"了。

翻译的解码

VNR改为使用和VTrans相同的SynCFG的来处理词条。
共享辞书中所有翻译、姓名、前缀、后缀、读法的词条都会被编译为SynCFG的语法。下边是一些SynCFG语法的例子：
翻译：こんにちは=>你好

SynCFG：x|||こんにちは|||你好

姓名：ゆい=>由依

SynCFG：m|||ゆい|||由依

后缀：ちゃん=>酱

SynCFG：m|||[[m]]ちゃん|||[[m]]酱

这里以最后一个SynCFG为例。它为【ちゃん】定义了翻译，并且这个翻译只有在姓名（m）后出现时，才会被应用。而应用了词条后的结果，仍然属于姓名（m）。

总的来说，SynCFG的语法如下。这个语法在VNR正在Cache里生成的词条的文件中是可以观察到的。
LHS_Role|||RHS_Source|||RHS_Target|||Features

Role的集合

比如，可以用[[m,n]]来匹配任何m（姓名）和n（noun）的集合。

多个Roles

在一个规则里，是可以定义多个Role的。
比方说，下边的规则可以用来翻译：ゆいちゃんを殺す
m|||ゆい|||由依

m|||[[m]]ちゃん|||[[m]]酱

v|||殺す|||杀死

x|||[[m]]を[[v]]||[[v]][[m]]

要注意的是，当使用多个相同的role在一个规则里时，一定要加上数字编号。比如：
x|||[[x#1]][[x#2]]||[[x#1]][[x#2]]
这条规则可以将相邻的两个位置的phrasae合并为一个。
另外，数字编号并不要求是连续增加的。比如下边的规则和上边的那个是一样的。
x|||[[x#10]][[x#5]]||[[x#10]][[x#5]]

再比如，下边的规则都是等价的：

x|||[[m,n]]を[[v]]|||[[v]][[m,n]]

另外当role只有一个时，翻译中的role的表达式是可以省略的。比如下边的规则都是等价的：
adj|||[[m,n]]の|||[[m,n]]的

adj|||[[m,n#1]]の=>[[m,n#1]]的

不要用字母Z。VNR内部保留Z做别的拥堵。自定义的role请用至少两个字母表示。单个的字母还是保留给VNR以后可能的用途吧。

与正则表达交织

当SynCFG的Role出现在匹配文本中时，由于技术困难，正则表达不可以出现namedgroup，比如下边这样的表达式是不可以出现的：
(A|BC|D)[[x]]
如果需要使用或的关系，可以使用unnamedgroup，比如下边：
(?:A|BC|D)[[x]]

翻译的代理

添加了新的代理词条，可以用来定义编码特定翻译Role的方法。
比方说：如果为m（姓名）定义了"佐藤=>佐藤"的词条。
那么VNR在编码m词条时，就会用佐藤来替代姓名了。
这样就可以避免姓名翻译词条会扰乱翻译的问题了。

要注意的是，代理词条的添加会是很危险的，词条提交后，VNR默认总是设定为私有的。大家一定要debug，debug，再debug，毫无问题后，再设定代理词条为公开才好。
另外，代理词条最好要避免出现简体字才好。比如：斉藤=>齐藤，由于齐是简体字，设定为代理词条可能会扰乱正体中文的翻译的。要选择那些比如：佐藤那样，不包含简体字的+翻译器认识的+一一对应的姓名作为代理词条才好。
再比如："ゆい=>由依"就不是一个好的代理词条。因为有些其他姓名（比如：ユイ、由依）的翻译也可能是由依。翻译和原始的姓名不是一一对应的。

提问：

不过如此的话需要添加的辞条数量似乎太庞大。

回答：其实这个SynCFG是阉割版的。缺少概率的多叉树和分词。我在训练vtrans的时候使用UniDic分词的，可以知道单词的边界的词性。我想下一步，首先删掉VNR对IPADIC和CaboCha的支持，改用和VNR服务器一样UniDic+align字典（比如EDICT）来分词。然后再把UniDic分词的词性的结果annotate到翻译里边。

另外，这样也可以让VNR鼠标查词的时间复杂度从O(N)降到O(1)（N为字典的容量），来实现瞬时的取词，不用像现在这样还要等待五秒钟。

提问：

是说syncfg定义的“杀死”只会在能识别[[m]]的位置使用，而其它的[[x]]部分则不会被翻译为杀死呢。

回答：

刚刚添加语法可以用比如吧：[[m,x]]来代表一个m和x的set。

提问：

看完英文例子了，可惜限制过大，基本只有很正经的GAL总是称呼标准人名才用得上

回答：

其实那个代理主要就是为了修正名字的。通过使用代理可以是的替换自定义人物姓名变得non-intrusive，机器翻译不会被替换后的1234.567之类的影响到了。

提问：

后缀的处理使得酱适用后因为依旧属于[[m]]所以后缀的の也能适用了吧？

回答：

恩，后缀规则可以被迭代。比如：如果定义了「さま=大人」和「の=的」的后缀，那么「さまの」就会被翻译成【大人的】。

然而，「のさま」也会被翻译成【的大人】，而这应该不是我们想要的。我觉得【の】最好先不要定义为后缀。比如，如果像下边这样定义：

m|||[[m]]さな|||[[m]]大人

adj|||[[m]]の|||[[m]]的

那么就只有「さなの」会被翻译为形容词，而「のさな」不会被翻译了。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!