Users report a bug where clicking the edit button on a category page leads to a 404 error, particularly when categories use Unicode or accented characters in their slugs (e.g., 日本語, santé). pinkd identified that the issue arises when the slug generation method is not set to ‘encoded’, especially in non-English environments like Japanese. Even newly created categories with empty slugs can trigger this error if Unicode characters are later used. pinkd confirmed that switching the ‘slug generation method’ site setting to ‘encoded’ resolves the 404 error. jeanmonod encountered the same issue with accented characters and received confirmation from Canapin that using ‘encoded’ slugs or removing accents fixes it. tshenry noted that ‘encoded’ should be the default when using non-English locales, and was unable to reproduce the bug with that setting enabled. Users suggest that the system should either reject multi-byte characters outright or display a warning when slugs contain unsupported characters to prevent this issue. The bug appears tied to how Discourse handles Unicode slugs without encoding, and the workaround is to ensure the ‘slug generation method’ is set to ‘encoded’.
This seems to be happening in a non-English environment. I was in a Japanese environment.
Any slugs will remain empty in the newly created category and there seems to be no problem
For reference, you can go to the edit screen by accessing this as a temporary solution.
Change the value of the number in the category accordingly. https://example.com/c/5-category/edit/general
I’m not sure if this is just my problem or a common bug, but I hope it helps.
I was able to reproduce it in the above step.
Even with newly created categories, the category edit button causes a 404 error when using Unicode slugs.
Hmm, I’m not able to reproduce the 404 with the slug generation method site setting set to encoded. I believe this should be enabled by default when you use a relevant default locale option.
I didn’t like long slugs and had turned it off before.
Selecting’encode’ for the slug generation method resolved the 404 error.
In such a situation, I think that it could be prevented by not accepting multi-byte characters or if there was a cautionary note.
In any case, it’s strange that the encoded string was assigned to the category that was emptying the slug …
