Customize emoji aliases #9986

New Issue

GiteaMirror · 2025-11-02T08:55:00-06:00

GiteaMirror commented

2025-11-02 08:55:00 -06:00

Originally created by @muzzsh on GitHub (Dec 18, 2022).

Feature Description

By now, there is no way to customize emoji alias(es) without rebuilding the gitea server since the predefined emoji aliases are hard coded.

This would be a problem when migrating from other VCS providers.
Here is an example, the ladybug couldn't be rendered properly because, in gitea, this emoji was called "lady_beetle" instead of "beetle" in bitbucket.org:

Can we add a configure section in the app.ini which is describing custom emoji aliases defined by the users(administrators)? Something like:

[ui.emoji_aliases]
beetle = lady_beetle
my_thumb = thumbsup
... ...

Screenshots

Originally created by @muzzsh on GitHub (Dec 18, 2022). ### Feature Description By now, there is no way to customize emoji alias(es) without rebuilding the gitea server since the predefined emoji aliases are hard coded. This would be a problem when migrating from other VCS providers. Here is an example, the ladybug couldn't be rendered properly because, in gitea, this emoji was called "lady_beetle" instead of "beetle" in bitbucket.org: ![image](https://user-images.githubusercontent.com/97163028/208285838-a4b340ac-ae76-4e7a-bf20-23a605b1814a.png) Can we add a configure section in the app.ini which is describing custom emoji aliases defined by the users(administrators)? Something like: **[ui.emoji_aliases]** beetle = lady_beetle my_thumb = thumbsup ... ... ### Screenshots ![image](https://user-images.githubusercontent.com/97163028/208285838-a4b340ac-ae76-4e7a-bf20-23a605b1814a.png)

GiteaMirror added the type/proposal type/feature labels 2025-11-02 08:55:00 -06:00

GiteaMirror commented

2025-11-02 08:55:01 -06:00

@muzzsh commented on GitHub (Dec 18, 2022):

A patch is ready to review https://github.com/go-gitea/gitea/pull/22156

@muzzsh commented on GitHub (Dec 18, 2022): A patch is ready to review https://github.com/go-gitea/gitea/pull/22156

GiteaMirror commented

2025-11-02 08:55:01 -06:00

@mrsdizzie commented on GitHub (Jan 4, 2023):

The real cause of this bug is that the emoji data used has not been updated from the upstream source. The alias beetle is a Unicode version 13 addition but Gitea still use Unicode version 12:

32e863439c/build/generate-emoji.go (L27-L28)

I haven't tried, but assuming it still works just changing that to 13 (or higher) and running the build script should update Gitea emoji data to match what others are using. I believe it was set to 12 initially because 13 was new enough that anybody who hadn't updated their font or os would see missing emoji symbol for anything newer than 12 which showed up in the suggestions.

You can see the 'beetle' / 'lady_beetle' alias change here:

https://github.com/github/gemoji/pull/173

I think that should be the proper fix for this issue since most other sources aren't using custom aliases that differ from Gitea but the ones Gitea have are just out of date from upstream that others are using too.

@mrsdizzie commented on GitHub (Jan 4, 2023): The real cause of this bug is that the emoji data used has not been updated from the upstream source. The alias beetle is a Unicode version 13 addition but Gitea still use Unicode version 12: https://github.com/go-gitea/gitea/blob/32e863439cc6a12c753675a73b603f878c8e3ff0/build/generate-emoji.go#L27-L28 I haven't tried, but assuming it still works just changing that to 13 (or higher) and running the build script should update Gitea emoji data to match what others are using. I believe it was set to 12 initially because 13 was new enough that anybody who hadn't updated their font or os would see missing emoji symbol for anything newer than 12 which showed up in the suggestions. You can see the 'beetle' / 'lady_beetle' alias change here: https://github.com/github/gemoji/pull/173 I think that should be the proper fix for this issue since most other sources aren't using custom aliases that differ from Gitea but the ones Gitea have are just out of date from upstream that others are using too.

GiteaMirror commented

2025-11-02 08:55:01 -06:00

@muzzsh commented on GitHub (Jan 4, 2023):

The real cause of this bug is that the emoji data used has not been updated from the upstream source. The alias lady_beetle is a Unicode version 13 addition but Gitea still use Unicode version 12:

32e863439c/build/generate-emoji.go (L27-L28)

I haven't tried, but assuming it still works just changing that to 13 (or higher) and running the build script should update Gitea emoji data to match what others are using. I believe it was set to 12 initially because 13 was new enough that anybody who hadn't updated their font or os would see missing emoji symbol for anything newer than 12 which showed up in the suggestions.

You can see the 'lady_beetle' alias change here:

github/gemoji#173

I think that should be the proper fix for this issue since most other sources aren't using custom aliases that differ from Gitea but the ones Gitea have are just out of date from upstream that others are using too.

It's really good to know how this issue was actually caused, and it's fairly well to fix this issue by updating the Unicode version from the upstream.

My concern is, Unicode version 13 was published on Mar.10th, 2020, nearly 3 years ago, but we still have the problem now.

Can we add the customizable emoji alias feature for the administrators as a workaround in case some changes are to be made by the upstream, but gitea doesn't catch up?

@muzzsh commented on GitHub (Jan 4, 2023): > The real cause of this bug is that the emoji data used has not been updated from the upstream source. The alias lady_beetle is a Unicode version 13 addition but Gitea still use Unicode version 12: > > https://github.com/go-gitea/gitea/blob/32e863439cc6a12c753675a73b603f878c8e3ff0/build/generate-emoji.go#L27-L28 > > I haven't tried, but assuming it still works just changing that to 13 (or higher) and running the build script should update Gitea emoji data to match what others are using. I believe it was set to 12 initially because 13 was new enough that anybody who hadn't updated their font or os would see missing emoji symbol for anything newer than 12 which showed up in the suggestions. > > You can see the 'lady_beetle' alias change here: > > [github/gemoji#173](https://github.com/github/gemoji/pull/173) > > I think that should be the proper fix for this issue since most other sources aren't using custom aliases that differ from Gitea but the ones Gitea have are just out of date from upstream that others are using too. It's really good to know how this issue was actually caused, and it's fairly well to fix this issue by updating the Unicode version from the upstream. My concern is, Unicode version 13 was published on Mar.10th, 2020, nearly 3 years ago, but we still have the problem now. Can we add the customizable emoji alias feature for the administrators as a workaround in case some changes are to be made by the upstream, but gitea doesn't catch up?

GiteaMirror commented

2025-11-02 08:55:01 -06:00

@muzzsh commented on GitHub (Jan 4, 2023):

Plus, as the "Emoji Meaning" mentioned:

Not to be confused with 🐞 Lady Beetle, 🪳 Cockroach, 🐛 Bug, 🐜 Ant or other emoji representations of insects. https://emojipedia.org/beetle/

"beetle" and "lady_beetle" are two different emojis, but in the case shown in the screenshot I posted earlier, the bitbucket.org emoji collection seems confused about "beetle" and "lady_beetle". It's not a problem at all in most scenarios (if Gitea supports ”beetle“ as a valid emoji either way), but when migrating from bitbucket.org (what I'm doing), it would be nicer if I could keep consistency because tons of historical commit messages are using the confused "beetle".

@muzzsh commented on GitHub (Jan 4, 2023): Plus, as the "Emoji Meaning" mentioned: _Not to be confused with [🐞 Lady Beetle](https://emojipedia.org/lady-beetle/), [🪳 Cockroach](https://emojipedia.org/cockroach/), [🐛 Bug](https://emojipedia.org/bug/), [🐜 Ant](https://emojipedia.org/ant/) or other emoji representations of insects._ https://emojipedia.org/beetle/ "beetle" and "lady_beetle" are two different emojis, but in the case shown in the screenshot I posted earlier, the [bitbucket.org emoji collection](https://bitbucket.org/DACOFFEY/wiki/wiki/BITBUCKET/EMOJI/Emoji) seems confused about "beetle" and "lady_beetle". It's not a problem at all in most scenarios (if Gitea supports ”beetle“ as a valid emoji either way), but when migrating from bitbucket.org (what I'm doing), it would be nicer if I could keep consistency because tons of historical commit messages are using the confused "beetle".

GiteaMirror commented

2025-11-02 08:55:01 -06:00

@mrsdizzie commented on GitHub (Jan 4, 2023):

My concern is, Unicode version 13 was published on Mar.10th, 2020, nearly 3 years ago, but we still have the problem now.

Agreed. It was never updated because there is no type of reminder system to do so once a year and this is probably the first reported issue to be seen as a result. I added the original set so that is probably my fault sorry!

Can we add the customizable emoji alias feature for the administrators as a workaround in case some changes are to be made by the upstream, but gitea doesn't catch up?

Gitea should catch up and I think it would fix most issues. I added a PR to update the emoji data set for all of Gitea #22342. Maybe since it involves no code change it could be back ported and get to users sooner than a new configuration option would be able to.

If another configuration option exists it should have its own good use case and not be needed only as a workaround for the general emoji dataset being out dated for a few years.

I'm not voting against any new option or trying to replace the original PR, just using this issue to highlight that the emoji data has gotten out of sync / date with upstream. If the PR is still helpful afterwards then great.

I commented in the PR above it is pretty easy to update the dataset when a new unicode version is supported upstream (which is shared with Github and many other places). It should probably be updated once per year whenever upstream adds new unicode versions.

@mrsdizzie commented on GitHub (Jan 4, 2023): > My concern is, Unicode version 13 was published on Mar.10th, 2020, nearly 3 years ago, but we still have the problem now. Agreed. It was never updated because there is no type of reminder system to do so once a year and this is probably the first reported issue to be seen as a result. I added the original set so that is probably my fault sorry! > Can we add the customizable emoji alias feature for the administrators as a workaround in case some changes are to be made by the upstream, but gitea doesn't catch up? Gitea should catch up and I think it would fix most issues. I added a PR to update the emoji data set for all of Gitea #22342. Maybe since it involves no code change it could be back ported and get to users sooner than a new configuration option would be able to. If another configuration option exists it should have its own good use case and not be needed only as a workaround for the general emoji dataset being out dated for a few years. I'm not voting against any new option or trying to replace the original PR, just using this issue to highlight that the emoji data has gotten out of sync / date with upstream. If the PR is still helpful afterwards then great. I commented in the PR above it is pretty easy to update the dataset when a new unicode version is supported upstream (which is shared with Github and many other places). It should probably be updated once per year whenever upstream adds new unicode versions.

GiteaMirror commented

2025-11-02 08:55:02 -06:00

@mrsdizzie commented on GitHub (Jan 4, 2023):

The initial missing emoji on :beetle: is now fixed

https://try.gitea.io/mrsdizzie/testme/issues/1#issuecomment-133733

To the other point, it does show a different emoji. bitbucket made the decision to create a custom alias 'beetle -> lady_beetle' in the past when the only emoji to exist was lady_beetle. Unicode then added a separate beetle emoji and now bitbucket is stuck unable to use the new 'beetle' alias because it already points somewhere else.

Having custom alias mapping would create the same problem for Gitea admins. In this example, once you set beetle -> lady_beetle the 'real' beetle alias no longer works. Of course, that mapping might be more important than using a new 'beetle' in your case and people have to work with existing text out of their control.

@mrsdizzie commented on GitHub (Jan 4, 2023): The initial missing emoji on `:beetle:` is now fixed https://try.gitea.io/mrsdizzie/testme/issues/1#issuecomment-133733 <img width="867" alt="Screenshot 2023-01-04 at 1 37 40 PM" src="https://user-images.githubusercontent.com/1669571/210626106-ecd9e2fe-2f2d-43a5-a22c-dfdcd98a3e83.png"> To the other point, it does show a different emoji. bitbucket made the decision to create a custom alias 'beetle -> lady_beetle' in the past when the only emoji to exist was lady_beetle. Unicode then added a separate beetle emoji and now bitbucket is stuck unable to use the new 'beetle' alias because it already points somewhere else. Having custom alias mapping would create the same problem for Gitea admins. In this example, once you set `beetle -> lady_beetle` the 'real' beetle alias no longer works. Of course, that mapping might be more important than using a new 'beetle' in your case and people have to work with existing text out of their control.

GiteaMirror commented

2025-11-02 08:55:02 -06:00

@mrsdizzie commented on GitHub (Jan 4, 2023):

Unrelated to the above but I think custom markdown filters are a cool and underused feature in Gitea and should come up any time somebody wants to change things without having to compile Gitea itself.

Untested, but you could maybe correct this problem on your Gitea instance now with a script like this:

[markup.markdown]
ENABLED         = true
FILE_EXTENSIONS = .md,.markdown
RENDER_COMMAND  = /Users/mrsdizzie/filter.pl

#!/usr/bin/perl

use strict;
use warnings;

while ( my $line = <> ) {
    $line =~ s/:beetle:/🐞/g;
    # or s/:beetle:/:lady_beetle:/g
    print "$line";
}

Though I doubt this gets called in all places that emoji alias conversion happens so maybe it isn't helpful if it needs to be inside of a label or somewhere particular that doesn't render markdown otherwise

@mrsdizzie commented on GitHub (Jan 4, 2023): Unrelated to the above but I think custom markdown filters are a cool and underused feature in Gitea and should come up any time somebody wants to change things without having to compile Gitea itself. Untested, but you could maybe correct this problem on your Gitea instance now with a script like this: ``` [markup.markdown] ENABLED = true FILE_EXTENSIONS = .md,.markdown RENDER_COMMAND = /Users/mrsdizzie/filter.pl ``` ```perl #!/usr/bin/perl use strict; use warnings; while ( my $line = <> ) { $line =~ s/:beetle:/🐞/g; # or s/:beetle:/:lady_beetle:/g print "$line"; } ``` Though I doubt this gets called in all places that emoji alias conversion happens so maybe it isn't helpful if it needs to be inside of a label or somewhere particular that doesn't render markdown otherwise

GiteaMirror commented

2025-11-02 08:55:02 -06:00

@muzzsh commented on GitHub (Jan 5, 2023):

Agreed. It was never updated because there is no type of reminder system to do so once a year and this is probably the first reported issue to be seen as a result. I added the original set so that is probably my fault sorry!

No one should be blamed for contributing to an open source project!

If another configuration option exists it should have its own good use case and not be needed only as a workaround for the general emoji dataset being out dated for a few years.

Having custom alias mapping would create the same problem for Gitea admins.

Agree, the new option might be abused using, leading to non-standard emoji aliases everywhere.

Of course, that mapping might be more important than using a new 'beetle' in your case and people have to work with existing text out of their control.

Yep, it's much more important to keep consistency than to have new features brought by the new Unicode version in the migration cases.

My suggestion is, to add a caution note in the doc to remind the admins to be aware of the downsides.

@muzzsh commented on GitHub (Jan 5, 2023): > Agreed. It was never updated because there is no type of reminder system to do so once a year and this is probably the first reported issue to be seen as a result. I added the original set so that is probably my fault sorry! No one should be blamed for contributing to an open source project! > If another configuration option exists it should have its own good use case and not be needed only as a workaround for the general emoji dataset being out dated for a few years. > Having custom alias mapping would create the same problem for Gitea admins. Agree, the new option might be abused using, leading to non-standard emoji aliases everywhere. > Of course, that mapping might be more important than using a new 'beetle' in your case and people have to work with existing text out of their control. Yep, it's much more important to keep consistency than to have new features brought by the new Unicode version in the migration cases. My suggestion is, to add a caution note in the doc to remind the admins to be aware of the downsides.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9986