-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No slug-representation of emojis/pictograms #49
Comments
@dalu Let's say I have a blog platform where I let my customers set the title of their posts. I want the title of their posts to be turned into a slug for the URL. For example, let's say there's a post titled "No slug-representation of emojis/pictograms", then I expect the URL to look something like But let's then say that a user has created two posts, whose titles contain more than just the "standard" ascii characters:
Then both those blog posts would have the slug I realize that there's is no obvious solution to this problem, in fact I said so in the last sentence of my original post, but forcing every platform to implement a huge custom substitution map for all of these characters is hardly a satisfying solution |
Facing same problem and its looks like there are no solution to make slug from any forbidden symbol :(
|
Thank you for this report and sorry it took so long, burnout is not nice... So first: https://github.com/rainycape/unidecode that I forked it to https://github.com/gosimple/unidecode Second: from the beginning I designed Third: I will not change default behavior (I don't want to break anyone) but it's possible to add some flag like Or maybe just export: Line 35 in a0807d1
so everyone could configure it themselves? I'm open to your ideas. |
This seems like a silly use case at first, but when creating a slug from a string containing emojis or pictograms, there is no representation of those characters. For example:
all yield empty strings.
I'm not sure how such a character would best be represented in a slug, but simply removing them could be problematic in some cases. Is this intentional?
The text was updated successfully, but these errors were encountered: