Hey all, WhyEssEff here
Over the past two-and-a-half or so years of being the sort-of-official emoji czar, the emote repository has grown to contain approximately 2300 distinct pictographs. As has been remarked over my tenure, this has unfortunately come with a lot of disarray. In order to address this, let me break it down in order to give proper context for it all.
The Problem
Hexbear’s emote shortcodes are notoriously obtuse and lack enforced standardization. A patchwork fix was applied to solve this in the refork, being keywords, but these only work when you are searching through the emote picker, not when you are using :shortcode-notation:.
The primary reasoning behind why this problem is a conundrum to fix is what I will call ‘shortcode rot.’ Essentially, what this entails is that:
- an unintuitive emote shortcode, for one reason or another, makes it into the emote repository.
- enough time passes for said emote to be used across multiple posts and comments.
- the shortcode now cannot be altered without breaking these posts’ and comments’ use of said emote.
The sources of unintuitive/unstandardized shortcodes, as far as I understand it, tend to fall into these categories:
- attempts at brevity (e.g.
:biderman:
) - emote is older than my tenure (e.g.
:loser:
, though this was one that I vividly remember making and recommending it be added back when we were stuck in the lifeboat discord, so this one’s still technically my fault ) - emotions and natural language representation of pictures are ambiguous (e.g. linguistics)
- syntactical ambiguity and non-standardization (e.g. one way this is used advantageously is that this is how we have three representations of 1984 in our emote base,
:19::84:
,:1984:
,:nineteeneightyfour:
) - WhyEssEff trying to be clever (e.g.
:debate-me-debate-me:
and:kubrick-stare:
) - the other ones that I can’t think of.
The Proposals
To preface, these are merely the options I am considering at the moment. Furthermore, the subsequent poll is merely me gauging feedback on these potential options. I reserve the right not to enact or fully enact whatever the majority opinion falls behind, because I a) have a life and may not be able to address the issue meticulously, b) can’t please everyone with whatever shortcode schema we do end up with, and c) kind of am attached to certain wrinkles in the repository and would ultimately be operating on my own discretion no matter what as the head and sole maintainer of the repository.
With that out of the way:
PROPOSAL 1: Discretionary Rename Effort
Plan of Action: As I sort through the emote database, I change the ones that stick out as unstandardized and/or ambiguous by my own discretion, updating them as I go and making a pinned masterpost that I update when I change a shortcode so people can stay informed about new shortcodes.
Pros:
- The one that is the most realistic for me.
- Solves the problem for the most erroneous ones.
Cons:
- My discretion is biased and fallible.
- Changes to shortcodes that may break some older content.
PROPOSAL 2: Strict Standardization and Total Overhaul
Plan of Action: All emotes are strictly standardized according to an enforced style guide, on top of the previous proposal.
Pros:
- Most accessible.
Cons:
- 99% chance I’m not going to do this because it sucks to implement.
- Really really breaking changes to shortcodes.
- Ehhhhhhhhhhhh
PROPOSAL 3: Do Nothing
Plan of Action: It is what it is
Pros:
- No broken shortcodes, archive preserved.
- I can just keep to a standard in the future.
- I don’t have to do anything.
Cons:
- The problem remains unsolved, so all the aforementioned issues.
The Poll
So, in order to collect feedback, here’s what I ask:
Respond with the emote that corresponds to the proposal in a top level comment, except for the last option, which I’ll explain below.
-
(:dean-smile:)
for Proposal 1: Discretionary Rename Effort. -
(:dean-malice:)
for Proposal 2: Strict Standardization and Total Overhaul. -
(:dean-frown:)
for Proposal 3: Do Nothing. -
(:dean-neutral:)
for something else, and explain what you suggest in your comment.
If you want to vote for a proposal that is suggested by someone else using , reply to their comment with a
Again, non-binding poll, I’m just trying to gauge the temperature on this. In about a week, I’ll check this post again and tally it all up, and then I’ll take that and decide how to move forward. Thanks all
IIRC the shortcodes are the key column of the emote. If you change them, then all previous uses in posts/comments will not load the emote. If you want to rename any, let me know and we can write a regex to go through and replace any instances in the database.
edit: also, its maybe possible we can enhance the inline emoji window to use keywords as well. would have to do some experimentation with it.
will keep this in mind, interesting option since keys are locked on frontend
I forgot, also we won’t be able to update federated posts in other instances, so those will get forever broken.
I haven’t explored other instances at all, but if updates sync is there an easy way to trigger the “there was an update to this post” push or whatever Lemmy uses to synchronize them?
maybe, i haven’t looks into it
Since the federation update, when I pick an emoji with the picker I get markdown to a URL that doesn’t contain the shortcode.
For example inserts:
![dean-neutral](https://www.hexbear.net/pictrs/image/48c31f9a-8487-48f0-afce-9db1db5fb5d6.png "emoji dean-neutral")
Notice that the url to the png:
https://www.hexbear.net/pictrs/image/48c31f9a-8487-48f0-afce-9db1db5fb5d6.png
doesn’t contain the shortcode.So right now the database has posts mixed between what I’ll call the “old format”
:shortcode:
and the “new format” with the URL. The new format shows up in other instances and the old format doesn’t.Shouldn’t it be possible to run a migration in the database, and switch the old format with the new for all posts? Then disable this on-the-fly shortcode substitution that the frontend is doing.
From then on we will have to use the picker, but the emoji can change name without braking old posts. And eventually the frontend conversion can be added to the backend to restore the old behaviour.
This would simultaneously solve the issue where emojis don’t show up in other instances some times.
Yeah we added extra code in our hexbear frontend to add handling for the ‘old format’ codes. We did sorta have plans to update all the old usages to the new one, but we just never got around to it during the big migration.
Now you have two problems.
I’m glad someone has already said this because this is what I was going to suggest as well. It wouldn’t be that hard to crawl with a simple python script.