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 Unified Ideographs) وربما بعض الكتل ذات الصلة، هو الحل الأكثر جدوى.
¹ «بعض الناس، عندما يواجهون مشكلة، يفكرون: ‘أعرف، سأستخدم التعبيرات المنتظمة.’ الآن أصبح لديهم مشكلتان.» — جيمي زافينسكي، http://regex.info/blog/2006-09-15/247
أعتقد أن الأمر قد تم إصلاحه
تم تنفيذ هذا كإعداد موقع enable inline emoji translation. وهو يسمح بـ 你好:smile: دون محاولة تحديد أحرف CJK الفردية، ويكون مفعلًا بشكل افتراضي لإعدادات اللغة الصينية واليابانية والكورية.
هل أنت متأكد من أنه يعتمد على الإعدادات اللغوية والمنطقة (Locale)؟ إعدادات الكاتب أم القارئ؟
أتمنى ألا يكون الأمر كذلك، لأنني لأسباب معينة أستخدم الإعداد en_US.UTF-8، رغم أنني لا أقطن في الولايات المتحدة، ولم أكن قد تحدثت أو كتبت بالإنجليزية الأمريكية من قبل، وعندما أكتب عبارة おはよ御座います
فأنا لا أكتب حتى باللغة الإنجليزية.
يمكنني القول إن الرموز التعبيرية أعلاه تبدو لي جيدة في محرر النصوص، وسأتمكن من إخبارك خلال لحظات عما إذا كانت تظهر بشكل صحيح عند قراءتي للموضوع بعد نشره.
(نعم، حتى عند القراءة بإعداد en_US.UTF-8، لا تزال تبدو جيدة. أظن أنها لا تعتمد في الواقع على الإعدادات اللغوية والمنطقة، رغم أنني أظن أيضًا أن المشكلة قد حُلت بشكل صحيح. أنا مهتم بمعرفة الطريقة التي حلت بها المشكلة بالضبط، لكن ليس بدرجة تدفعك للقيام بأي عمل جاد للتحقق مما إذا كان ذلك سيسبب أي صعوبة.)
توجد إعدادات للموقع خاصّة بالمنتديات، والتي تُضبط بناءً على القيمة المحددة في إعداد الموقع اللغة الافتراضية. لا تعتمد هذه الإعدادات على تفضيلات القراء أو الكتاب، بل تساعد المشرف على تكوين منتدى بلغة محددة. يمكنك قراءة المزيد عن هذا الموضوع هنا: Locale-specific defaults for site settings (`locale_default`)
لا يزال بإمكان المشرفين تكوين جميع هذه الإعدادات كما يشاؤون. لذا، يمكن لمشرف موقع تكون لغته الافتراضية الإنجليزية أن يسمح بعد ذلك بعناوين ومنشورات أقصر أو باستخدام المزيد من الأحرف في أسماء المستخدمين. يتغير فقط القيمة الافتراضية للإعداد التي قد تكون الأكثر منطقية. لذلك، حتى في المنتدى الذي تكون لغته الافتراضية الإنجليزية، يمكن للمشرف تكوين إعداد الموقع enable_inline_emoji_translation بحيث لا تكون هناك حاجة إلى مسافة.