Это полезный инструмент модерации, но он плохо поддерживает символы, отличные от латинских, и наличие таких символов может даже влиять на обнаружение английских слов и цифр. В качестве примера возьмём упрощённое китайское слово «测试» (тест). В списке отслеживаемых слов содержатся три элемента: «测试», «Test» и «123». В приведённом ниже тесте ни один из трёх примеров не сработал как отслеживаемое слово.
Я поискал на сайте и нашёл ещё одну похожую проблему, касающуюся цензурируемых слов: Censored words do not respect word boundaries in non-latin alphabet . Похоже, это общая проблема всей системы сопоставления отслеживаемых слов?
2 лайка
Спасибо за отчет, это будет исправлено в
main ← fix/watched-words-cjk-boundaries
merged 05:04PM - 16 Feb 26 UTC
Watched words failed to match in CJK (Chinese, Japanese, Korean) and other space… less scripts because word boundary detection relied on whitespace or non-word characters. Languages like Chinese don't use spaces between words, so "测试" inside "这是一个测试文本" was never matched.
Introduce a SPACELESS_SCRIPTS constant covering Han, Hiragana, Katakana, Hangul, Thai, Lao, Myanmar, Khmer, and Tibetan Unicode ranges. Update `match_word_regexp` for both Ruby and JS engines so that characters from these scripts are treated as word boundaries. This allows a CJK watched word to match when surrounded by other CJK characters, and a Latin watched word to match when adjacent to CJK text (e.g., "Test" in "我的Test很好"), while still preventing partial Latin matches (e.g., "Testing" does not match "Test").
Also fix the admin watched word testing modal to use `RegExp.exec()` with capture group extraction instead of `String.match()`, since the new boundary patterns include a leading consuming group.
Remove the outdated "non-chrome browsers do not support lookbehind" comment — all major browsers have supported lookbehind since 2023.
https://meta.discourse.org/t/71288
https://meta.discourse.org/t/396109
2 лайка
