emojiSlugMappingGen.py

wheel (GitLab) wheel (GHA via nightly.link)

We have moved to https://codeberg.org/KOLANICH-tools/emojiSlugMappingGen.py, grab new versions there.

Under the disguise of "better security" Micro$oft-owned GitHub has discriminated users of 1FA passwords while having commercial interest in success of FIDO 1FA specifications and Windows Hello implementation which it promotes as a replacement for passwords. It will result in dire consequencies and is competely inacceptable, read why.

If you don't want to participate in harming yourself, it is recommended to follow the lead and migrate somewhere away of GitHub and Micro$oft. Here is the list of alternatives and rationales to do it. If they delete the discussion, there are certain well-known places where you can get a copy of it. Read why you should also leave GitHub.

---

This is a tool to generate mappings from emoji slugs into emojis for use by tools doing automatic replacements.

To generate mappings in mo format, type

python3 -m emojiSlugMappingGen -l license.txt > emoji.mo

To generate mappings in json format, type

python3 -m emojiSlugMappingGen -f json:fancy -l license.txt > emoji.json

Pregenerated files can be downloaded here.

Limitations

Currently some compound emoji (i.e. "👩🏿\u200d❤\ufe0f\ufe0f\u200d👨🏻") can contain a sequence of 2 presentation selectors right after each other (\ufe0f\ufe0f). emojiNorm.normalizeEmoji (intended to fix artificially created (i.e from the incomplete data, such as GitHub emoji API endpoint, that excludes zwjs and presentation selectors)/edited emoji sequencies) breaks those emoji since it first strips all emoji presentation selectors, and then generates them from scratch. It seems that for those emoji the only way is to remember that they are constructed this way. Currently I'm not sure how to handle them, so they are broken.

I guess for now this can be mitigated by non-doing normalization in some cases.