Hi,
It seems that Discourse has some trouble dealing with Chinese characters. Our users cannot submit topics/posts if they use in chinese? In this case, I can see that it’s a long message but we still get the “Body seems unclear” message.
Any idea?
I see what is happening here.
We automatically disable this on Chinese forums but your forum appears to be English with a Chinese category.
Just set body min entropy to 0 in site settings.
Hum. Correction. It seems setting the body min entropy to 0 did not fix the issue. I tried with another text in Chinese and I still get the same error even though the body min entropy is set to 0


Did i miss something?
Hi,
Following up on this issue. I’m running some test with the latest version of discourse.
Body min entropy is set to 0. Same for Title min entropy.
When trying to create a topic with the body below I get the “Body unclear” error:
【澳門日報5月29日消息】國際會議協會(ICCA)日前發佈《二○一七年國際協會會議市場年度報告》。當中澳門多項評比的排位連續兩年均有上升,其中全球城市排名由一六年的七十二名躍升至第六十五名;亞太區域城市排名升一位至第十六,排名超過瑞士的日內瓦、澳大利亞的布里斯班、阿拉伯聯合酋長國的迪拜、韓國的釜山和濟州等城市
Is there a quick work around on this? My Chinese users are getting nervous because of this issue.
Thx
Seb
I’ve clarified this issue. But newbie is only able to put single picture on a post. So just a evidence and conclusion.
Conclusion, for both title and body
Извините, что поднимаю эту тему, но мы столкнулись с той же проблемой на нашем форуме, который в основном на английском, но с некоторыми разделами на других письменностях. Установка body min entropy в 0 не помогла.
Похоже, проблема в том, что использование некоторых латинских букв срабатывает в проверке на все заглавные буквы. Вот пример сообщения, которое вызывает уведомление «Текст кажется неясным»:
Я проверил: моя открытка, отправленная 15 августа в Россию, была получена 13 октября, но та, что отправлена 27 октября, ещё не получена. Прошло уже 36 дней (хотя открытки из той же партии, отправленные в разные страны, тоже не дошли).
Так как я просто опустил их в почтовый ящик, не совсем понятно, не дошли ли они из-за этого… Если вы в группе UCPC в WeChat, может, стоит спросить у других?
Является ли allow uppercase posts единственным решением? На форумах, подобных нашему, где основной язык — английский, включение этой опции не идеально, но я также понимаю раздражение пользователей, которые вводят валидное сообщение на своём языке и натыкаются на эту ошибку. Не поможет ли здесь проверка соотношения заглавных букв к общему размеру текста?
Именно это и делается, и в вашем примере соотношение составляет 100%.
Если язык по умолчанию форума установлен на китайский, мы автоматически корректируем эти настройки, но если в одном экземпляре используются смешанные языки, вам нужно настроить этот параметр вручную.
Если текст содержит символ из одного знака, у которого нет варианта верхнего/нижнего регистра (как, например, в китайском), то такой текст автоматически не считается полностью заглавным. Это можно проверить, сопоставив с регулярным выражением /\p{Lo}/ в этом месте.
Такой подход не потребует специальной настройки для форумов, где преимущественно используются языки zh/ko/ja, и будет хорошо работать также на форумах со смешанными языками, применяя правило «разрешить заглавные буквы» только там, где используются только символы, способные быть заглавными.
Возможно, аналогичную логику можно также использовать для оптимизации существующей проверки на полное написание заглавными буквами: если текст соответствует выражению /\p{Ll}/ (строчная буква, имеющая вариант верхнего регистра), то текст не считается полностью заглавным.
Звучит как отличная идея для запроса на включение изменений!
Мои навыки в Ruby практически отсутствуют, но я могу попробовать собрать что-то, так как проблема в некоторой степени локализована.
Сказав это, я вижу TODO в начале этого файла, которое, похоже, связано с этой конкретной строкой кода. Достаточно ли просто удалить require, или к этому PR стоит привлечь кого-то, кто разбирается в этом?
Я попытался решить это в FIX: Allow all caps within CJK text by mentalstring · Pull Request #27900 · discourse/discourse · GitHub
Я ещё далёк от того, чтобы быть разработчиком на Ruby, так что проявите терпение. ![]()
Спасибо @mentalstring, я использовал ваш PR как вдохновение для
В нём также улучшена производительность и улучшена поддержка нелатинских локалей ![]()
(cc @lindsey)
Отлично, что этот вопрос решается!
Мы ведем международный форум: основной язык — английский, но есть категории на других языках, и это было давней проблемой.
Теперь, когда skipped_locale используется только для seems_unpretentious, не могли бы мы исключить ‘ko’, поскольку в современном корейском языке используются пробелы? Учтите, что я не владею корейским, так что, возможно, стоит перепроверить это.
Пока я удерживаю ваше внимание, есть ещё одна вещь, которая, как мне кажется, могла бы стать простым улучшением для TextSentinel, но я не решился трогать её (снова: я не разработчик на Ruby). Если у вас есть минутка, думаю, это довольно просто и может дать прирост производительности «бесплатно».
Насколько я понимаю, здесь проверяется, превышает ли слово лимит: текст разбивается на слова, вычисляется длина каждого, сканируются все длины, чтобы найти максимальную, и только затем она сравнивается с лимитом.
Может быть, мы могли бы пропустить всё это, просто попробовав сопоставить текст с чем-то вроде /\p{Alnum}{#{max_word_length + 1},}/ (синтаксис, вероятно, неверный, но надеюсь, идея ясна)?
Не зная внутренних механизмов Ruby, полагаю, такой подход скорее остановит проверку сразу при совпадении, а если слишком длинного слова нет (что случается чаще всего), текст будет просканирован только один раз, без разбивки, проверки длины отдельных слов и т. д.
Извините, если я перехватываю тему, но так как новый PR уже слит, я не уверен, куда лучше это написать: возможно, это слишком мелкая правка для отдельной темы, но выглядит как лёгкая победа. Смело берите это в работу.
Я тоже не знаю. Но очень хотел бы получить подтверждение от носителей корейского языка.
Это отличная идея ![]()
Ура!
Спасибо, что нашли время.
Может быть, один из корейских переводчиков (/cc @9bow, @alexkoala, @changukshin
) сможет подтвердить, что в современном корейском языке слова разделяются пробелами, как в романских/латинских языках, чтобы Discourse мог использовать это предположение при обработке корейского текста для поиска слишком длинных слов? ![]()