I have enabled (some) Unicode characters in usernames and everything works as expected.
When I tried using Unicode characters in a category slug, it converted it to percent encoding and allowed me to save the changes, but I was no longer able to access the category topic list because I’d get ERR_TOO_MANY_REDIRECTS.
Some work has been done on this in the past, but I do not think the issue you ran into has been addressed. What I think happened is that you have the slug generation method set to ‘ascii’ and you directly entered a category slug that has non-ascii characters in it. I can reproduce that issue on my site with the slug generation method set to ‘ascii’ and the following text (yetersizliği) entered directly into the Category Slug field:
If I don’t enter anything into the Category Slug field, DIscourse will create the slug correctly when the slug generation method is set to ‘ascii’.
With the slug generation method is set to ‘encoded’, Discourse handles creating the slug correctly both when I leave the Category Slug input empty and if I directly enter the non-ascii slug into the input.
So it seems that the issue is that when the slug generation method is set to ‘ascii’, non-ascii slugs can still be entered into the Category Slug field. This causes a redirect issue that can only be fixed from the Rails console.
That’s exactly what I did, I was editing a category that had been previously created—both its name and slug. I didn’t know about the slug generation method setting, and, even though I later found it to be set to ascii, the slug was encoded anyway.
This kind of coercion might make sense, but only if the encoded slug can be later recognized, ignoring the setting in a similar way.
