Я включил (некоторые) символы Unicode в именах пользователей, и всё работает как ожидалось.
Когда я попытался использовать символы Unicode в слаг категории, система преобразовала их в кодировку с процентами и позволила сохранить изменения, но я больше не мог получить доступ к списку тем категории из-за ошибки ERR_TOO_MANY_REDIRECTS.
Это не критическая проблема, но она может нарушить работу, поэтому предлагаю либо полностью реализовать эту функцию, либо добавить защиту от подобных ситуаций.
Ранее по этому вопросу уже проводилась работа, но, по-моему, проблема, с которой вы столкнулись, не была решена. Скорее всего, у вас установлен метод slug generation method (генерации слага) в значение ‘ascii’, и вы вручную ввели слаг категории, содержащий не-ASCII-символы. Я могу воспроизвести эту проблему на своём сайте, когда slug generation method установлен в ‘ascii’, и в поле «Category Slug» (Слаг категории) вручную ввести следующий текст (yetersizliği):
Попытка загрузить список этой категории завершается ошибкой.
Если я не ввожу ничего в поле «Category Slug», Discourse корректно создаст слаг, когда slug generation method установлен в ‘ascii’.
Когда slug generation method установлен в ‘encoded’, Discourse корректно создаёт слаг как в случае, если поле ввода «Category Slug» оставлено пустым, так и если я вручную ввожу не-ASCII-слаг в это поле.
Похоже, проблема заключается в том, что при установке slug generation method в ‘ascii’ в поле «Category Slug» всё ещё можно ввести слаг с не-ASCII-символами. Это вызывает ошибку перенаправления, которую можно исправить только через консоль Rails.
Именно так я и поступил. Я редактировал категорию, которая уже была создана — как её название, так и слайг. Я не знал о настройке метод генерации слайга, и, хотя позже выяснил, что она установлена в значение ascii, слайг всё равно был закодирован.
Такая принудительная конвертация может иметь смысл, но только если закодированный слайг впоследствии может быть распознан, игнорируя настройку подобным же образом.
