Page MenuHomePhabricator

Support `:emoji:` in Remarkup
ClosedPublic

Authored by epriestley on Sep 28 2014, 10:09 PM.

Details

Summary

Ref T1191. This actually works without T1191, but makes emoji use on the desktop easier.

Test Plan

Screen_Shot_2014-09-28_at_3.07.57_PM.png (495×627 px, 32 KB)

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Support `:emoji:` in Remarkup.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added reviewers: chad, btrahan.
btrahan edited edge metadata.
btrahan added inline comments.
src/applications/macro/markup/PhabricatorEmojiRemarkupRule.php
23

does this list come from somewhere?

can we pht it for maximal cross-language lolz?

the answers I know not.

This revision is now accepted and ready to land.Sep 29 2014, 2:27 AM

The list is approximately taken from Gemoji (https://github.com/github/gemoji), which is similar to (or possibly identical to?) this list, which seems widely adopted:

http://www.emoji-cheat-sheet.com

The only real change I made was to allow the use of - in place of _, so :tropical_fish: and :tropical-fish: both work.

On pht(), we have a couple of cases like this (another is Fixes T123) where pht() isn't really the right fix, since if you write :el-fisho: and I write :fish:, both should be turned into a fish emoji when either of us is viewing the text. We really need to say "no matter what language the viewer speaks, all of 'fish', 'el fisho', 'fishiji', etc., convert into the fish glyph".

This will probably get complicated because I'm guessing there are cases where a word like "fisho" means "fish" in Spanish, but means "apple" in Greek, so if we see :fisho: we don't know whether it should be turned into a fish glyph or an apple glyph. We can't always just check who wrote it, either, because it may appear in a commit message we can't figure out the author for, or a README.remarkup.

I think we'll probably end up with some new pht()-like function which expands into a list across all possible translations, and then maybe some way for installs to select which language wins in the case of collisions, so primarily-Spanish installs can choose Spanish over Greek, and primarily-Greek installs can do the opposite.

Overall, I think this is complicated enough to push off to a future date, though. There hasn't been very much demand for it yet (one install, in T5586).

This revision was automatically updated to reflect the committed changes.