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:![]()
![]()
방해가 될까 봐 걱정됩니다. 이 문제에 대한 수정이 실제로 구현된 적이 있나요?
여기서는 정규식을 사용하는 것이 적합하지 않다고 생각합니다. (역시나.¹) 문자가 CJK 통합 한자 블록 중 하나인지, 그리고 관련 블록에 속하는지 확인하는 방식이 작동할 가능성이 더 높아 보입니다.
¹ “어떤 사람들은 문제에 직면했을 때 '아, 정규식을 쓰자’라고 생각합니다. 그리고 그들은 이제 두 가지 문제를 갖게 됩니다.” — 제이미 자윈스키(Jamie Zawinski), http://regex.info/blog/2006-09-15/247
수정된 것 같습니다.
이 기능은 enable inline emoji translation 사이트 설정으로 구현되었습니다. 개별 한자(CJK) 문자를 식별하려 하지 않고 你好:smile:과 같은 인라인 이모지 번역을 허용하며, 중국어, 일본어, 한국어 로케일에는 기본적으로 활성화되어 있습니다.
로케일에 따라 달라진다는 확신이 있으신가요? 작성자의 로케일인가요, 읽는 사람의 로케일인가요?
어떤 이유에서든 저는 로케일을 en_US.UTF-8으로 사용하고 있기 때문에, 그렇게 되지는 않기를 살짝 희망하고 있습니다. 저는 미국에 있지 않으며, 미국식 영어로 말하거나 글을 써본 적도 없고, おはよ御座います
를 입력할 때조차 영어를 입력하는 것이 아니기 때문입니다.
에디터에서는 위의 이모지가 저에게 정상적으로 보입니다. 그리고 게시된 글을 읽을 때 정상적으로 렌더링되는지는 잠시 후 알려드릴 수 있을 것입니다.
(네, en_US.UTF-8으로 읽을 때도 여전히 정상적으로 보입니다. 실제로는 로케일에 따라 달라지지 않는다고 추측하고 있지만, 문제가 제대로 해결되었을 것이라고도 추측합니다. 다만 정확히 어떻게 해결했는지 궁금하긴 하지만, 알아내기가 어려울 정도로까지 질문할 정도는 아닙니다.)
포럼에는 기본 로케일 사이트 설정에서 선택된 값에 따라 조정되는 사이트 설정이 있습니다. 이러한 설정은 독자의 선호도나 작성자의 선호도에 따라 달라지는 것이 아니라, 관리자가 특정 언어에 맞게 포럼을 구성하는 데 도움을 줍니다. 이 주제에 대해 더 자세히 알고 싶다면 다음 링크를 참고하세요: Locale-specific defaults for site settings (`locale_default`)
관리자는 여전히 이러한 모든 설정을 원하는 대로 구성할 수 있습니다. 예를 들어 기본 로케일이 영어인 사이트의 관리자는 더 짧은 제목과 게시글을 허용하거나 사용자 이름에 더 많은 문자를 사용할 수 있도록 설정할 수 있습니다. 변경되는 것은 설정의 기본값 중 가장 적절한 값일 뿐입니다. 따라서 기본 로케일이 영어인 포럼에서도 관리자는 enable_inline_emoji_translation 사이트 설정을 구성하여 이모지 변환 시 공백이 필요 없도록 설정할 수 있습니다.