[BUG] 翻译错误/更像是关键词配对异常问题

[qwedc001]

对于Atcoder Better:

此位置的Guest在比赛的时候会变为Contestant，应该是触发了 Atcoder Better 中 contest 的匹配条目，实际展示效果会是比赛ant。

修改建议：加入 contestant 翻译项并翻译 / 如果这里是意外情况，请限制一下匹配条目的翻译匹配范围。

类似的行为还会出现在 codeforces 上，我记着曾经触发过比赛 A 题叫 XXX Problemset 被自动匹配成了问题集之类的，但是我找不到了，不知道修了没有。

[beijixiaohu]

好的，有空我看看

[wrk-123]

举个例子，这里的 D 题 https://codeforces.com/contest/1984

[beijixiaohu]

举个例子，这里的 D 题 https://codeforces.com/contest/1984

这个我知道，之所以没修复是因为他并不是bug，而只是一种权衡。

我将替换规则分为严格和不严格，由规则中的 isStrict 字段指定，

• 不严格：直接对目标文本进行replace替换，

• 严格：要求规则文本与目标文本完全一致时才进行替换

显然不严格的规则更容易编写，性能更高，且更有健壮性，只是会偶尔产生这种奇怪的替换

比如如下文本：

The Contest will start in 10 minutes.

如果使用不严格匹配，只需要如下规则：

"rules": {
    "The Contest will start in": "比赛将在",
    "minutes": "分钟后开始",
}

这看起来很奇怪，但比起使用一个正则表达式，我认为它的性能开销要小得多，因为一个页面上的文本元素实在是太多了

而 D 题这里应用的就是一个不严格的规则 .datatable，

如果有更好的实现思路，欢迎分享讨论。

[beijixiaohu]

非常高兴分享关于该问题的新进展，

首先我之前的观点是错误的，实测发现，使用正则匹配的性能实际上是非常优秀的，以上楼的 Problem 词条为例，

同样的页面与匹配区域（会匹配约8k个node），使用首尾断言正则 ^\s*Problem\s*$ 匹配耗时只有 0.4 ms：

且这样不会产生错误的替换，比如下方的题目 ''a'' String Problem 中的 Problem 不会被替换。

---

173 在新的扩展中，会提供三种匹配模式：正则、模板、属性选择

正则匹配： 对区域中的所有文本节点进行正则匹配

模板匹配： 支持编写HTML模板，匹配器会结合多个特征来快速锁定目标元素并完成文本替换

有了模板匹配后，可以轻松完成以前难以完成或者效果不好的本地化任务，如下图所示

属性选择： 替换元素的任意属性值，用于本地化文本来源为元素属性的元素，比如 input[type="button"]

扩展中还将匹配和替换进行分离，并使用任务队列进行调度管理，以优化体验，此外还将设计完善的性能监测告警系统，具体敬请期待！