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
I seem to have fixed it using the Rails console:
This isn’t a show-stopper, but it can break things, so I’d suggest it should either be fully implemented or guarded against.
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:
After saving the category:
Attempting to load that category list then fails.
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’.
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.
So what we need is a model validation on save here right?
I can take it.
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.