If we post two pictograms consecutively, one pictogram is not displayed as shown in the picture below.
Is there a solution?
![]()
If we post two pictograms consecutively, one pictogram is not displayed as shown in the picture below.
Is there a solution?
![]()
like this?
:bowing_man: :two_hearts:
* note the space between the colons
text
![]()
Yes!
I understood that two emoticons will be displayed if space is entered.
However, in my web site, when I put two emoji characters, the space does not come in automatically.
This is an error caused by a difference in notation between languages.
While English puts a space between words, on the other hand, Japanese and Chinese do not put space between words.
You’re saying your keyboard doesn’t have a space bar?
No it is not
As a premise, Japanese and Chinese do not put spaces between words.
So pictograms are inserted consecutively after the word without inserting a space.
Then, in discourse pictograms are not displayed correctly, text is displayed instead.
So instead of the ASCII space character, you have only the “full width space” character and Discourse is not interpreting that as a “space”.
Or users are conflating words and emojis and entering them as though they were the same.
I imagine recognition of the full-width space could be coded in. But educating members to treat words and emojis as different things might not be so easy.
Maybe if the auto-complete emoji picker automatically added a space before the first and after the last colons?
I understand this problem and we may look at adding some sort of setting for Chinese. The problem is it is fairly expensive to figure out if a letter is in Chinese as it is a massive regular expression and we do not want to carry all this code.
What I would be open here for is a “mode” where we do not do a “is letter” check prior to emojis which we can enable in Chinese sites so you can butt up emojis against letters. But this change would be global so test:small_airplane: would render as test
which I guess is fine for you.
In my opinion, if discorse automatically puts a space before an emoticon, problems will be solved in all Chinese, Korean and Japanese.
Initially, this problem arises because Japanese and Chinese people insert pictograms without putting a space at the end of the sentence or in the middle of the sentence.
This is because it is based on the language notation that it creates sentences without spaces, so there is no choice.
There is no need to let the program decide whether it is Chinese or not. Would not it be okay for the program to judge only whether or not there is space before emoji?
![]()
![]()
![]()
こんにちは:smiley:![]()
![]()
Bonjour. Une correction a-t-elle été mise en œuvre pour ce problème ?
Je ne pense pas qu’une expression régulière soit ce que vous souhaitiez ici. (Comme d’habitude.¹) Vérifier si le caractère fait partie des Idéogrammes unifiés CJK et éventuellement de certains blocs apparentés semble plus susceptible de fonctionner.
¹ « Certains gens, lorsqu’ils sont confrontés à un problème, pensent : “Je sais, j’utiliserai des expressions régulières.” Maintenant, ils ont deux problèmes. » — Jamie Zawinski, http://regex.info/blog/2006-09-15/247
Je pense que c’est corrigé
Cela a été implémenté en tant que paramètre du site enable inline emoji translation. Il permet 你好:smile: sans essayer d’identifier les caractères CJK individuels, et est activé par défaut pour les locales chinoise, japonaise et coréenne.
Êtes-vous sûr que cela dépend de la locale ? Celle de l’auteur ou du lecteur ?
J’espère plutôt que non, car, pour des raisons qui m’ont échappées, j’utilise la locale en_US.UTF-8, bien que je ne sois pas aux États-Unis, que je n’aie jamais parlé ni écrit en anglais américain, et que, lorsque je tape おはよ御座います
, je ne tape même pas en anglais.
Je peux dire que dans l’éditeur, l’emoji ci-dessus me semble correct, et je pourrai vous dire dans un instant s’il s’affiche correctement lorsque je le lirai après publication.
(Oui, en lisant avec en_US.UTF-8, il semble toujours correct. Je suppose que cela ne dépend pas vraiment de la locale, même si je suppose aussi que le problème est correctement résolu. Je suis curieux de savoir comment vous l’avez résolu, mais pas assez pour vous demander de faire un travail sérieux pour vérifier si cela pourrait causer des difficultés.)
Il existe des paramètres de site pour les forums qui sont ajustés en fonction de la valeur sélectionnée dans le paramètre de site locale par défaut. Ils ne dépendent pas des préférences des lecteurs ou des rédacteurs, mais aident l’administrateur à configurer un forum pour une langue spécifique. Vous pouvez en savoir plus à ce sujet ici : Locale-specific defaults for site settings (`locale_default`)
Les administrateurs peuvent toujours configurer tous ces paramètres comme ils le souhaitent. Ainsi, un administrateur d’un site dont la langue par défaut est l’anglais peut toujours autoriser des titres et des messages plus courts ou l’utilisation de plus de caractères dans les noms d’utilisateur. Ce qui change, c’est uniquement la valeur par défaut du paramètre qui semble la plus logique. Ainsi, même sur un forum dont la langue par défaut est l’anglais, l’administrateur peut configurer le paramètre de site enable_inline_emoji_translation pour qu’aucun espace ne soit nécessaire.