I’ve been in contact with Transifex. It looks like they are doing some magic with Emojis that they shouldn’t do for YML files used by Rails.
– Whenever a Unicode sequence is included in a YML file, it detects this and represents this in Transifex Web Editor using the corresponding emoji symbol. That way there will be no need for translators to try to find what this code means.
– Whenever an emoji is added by a translator via Transifex Web Interface, our YML handler compiles the file, identifies the emojis that might be included in translations and then replace them with their corresponding Unicode representation in the generated YML files. Strings that contain such characters are enclosed in double quotes.
I hope they will stop doing this when the Rails YML handler is used. It doesn’t make sense, because the Psych YML parser supports Emojis, but doesn’t like the escaped Unicode characters.
A similar problem prevented the auto-updating of the core/client.yml file since the beginning of August. Their YML handler silently fails (well, it reports that it failed to fetch the file) when the YML file contains an Emoji. I fixed that on our side, until Transifex supports Emojis within YML files.
Well, the Japanese translations on Transifex still use Emojis. Unfortunately Transifex didn’t fix the root cause either, so the locale files haven’t been updated for quite some time.
You are welcome to contribute to the Japanese translations on Transifex if you need it for your community. We can start pulling translations again as soon as Transifex fixes the problem or translators remove the problematic Emojis.
No, Transifex didn’t stop putting Unicode in the locale files that isn’t supported by Ruby, but I added a workaround to our pull script that replaces the Unicode Surrogates with the actual Emojis.