源地址：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]]
x ||| [[m,n#1]]を[[v#2]] ||| [[v#2]] [[m,n#1]]
x ||| [[m,n#1]]を[[v#2]] ||| [[#2]] [[#1]]
x ||| [[m,n#1]]を[[v]] ||| [[v]] [[#1]]
另外当role只有一个时，翻译中的role的表达式是可以省略的。比如下边的规则都是等价的：
adj ||| [[m,n]]の ||| [[m,n]]的
adj ||| [[m,n#1]]の => [[m,n#1]]的
adj ||| [[m,n#1]]の => [[#1]]的
adj ||| [[m,n#1]]の => [[]]的
adj ||| [[m,n]]の => [[]]的
自定义Role
我建议大家用n来代表名词，v代表动词，x代表未知词组，m代表姓名。
如果大家需要自定义Role，可以使用[_a-yA-Y0-9]中的字母任意搭配，比如可以用adj来代表形容词。
基本和C等变成语言中的变量名字是一样的，但是要注意：
- 不要用字母Z。VNR内部保留Z做别的拥堵。自定义的role请用至少两个字母表示。单个的字母还是保留给VNR以后可能的用途吧。
与正则表达交织
当SynCFG的Role出现在匹配文本中时，由于技术困难，正则表达不可以出现named group，比如下边这样的表达式是不可以出现的：
(A|BC|D) [[x]]
如果需要使用或的关系，可以使用unnamed group，比如下边：
(?: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]]的
那么就只有「さなの」会被翻译为形容词，而「のさな」不会被翻译了。