Closed
Bug 740724
Opened 13 years ago
Closed 10 years ago
Some text code are replaced to smiley images
Categories
(Chat Core :: General, defect)
Chat Core
General
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 954572
People
(Reporter: tetsuharu, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
Some text codes are replaced to smiley images.
STR:
1. Open Twitter timeline
2. Post "o_o".
Result:
Showing smile images on timeline.
smile images: http://mxr.mozilla.org/comm-central/source/mail/components/im/smileys/manga_stunned.png
This causes by replacing text code with the table, http://mxr.mozilla.org/comm-central/source/mail/components/im/smileys/theme.js .
This behavior sometimes are useful and cute.
But this breaks text & confuses users.
I think that this replacing behavior should be optional or are removed from Thunderbird Instant Messaging.
Comment 1•13 years ago
|
||
It exists the about:config entry mail.display_glyph. Maybe it works also with IM. If not, could this be an option if IM is using this?
Comment 2•13 years ago
|
||
I don't really see how you can post "o_o" to mean something else than a smiley.
If you want to disable emoticons, set the pref messenger.options.emoticonsTheme to the value "none".
Reporter | ||
Updated•13 years ago
|
Version: 14 → Trunk
Reporter | ||
Comment 3•13 years ago
|
||
Sample image for next comment.
Reporter | ||
Comment 4•13 years ago
|
||
I think that, it is bad that the current behavior which replaces any string to image by default.
This behavior has following problems:
"o_o" is written as "(o_o)" as same meaning .
However, the current implementation replaces (o_o) into (<image/>), (ref. sample 1 in attachment). This is strange.
And also normal text which is not ascii art, e.g. HN, are replaced by the same token (ref. sample 2 in attachment):
"piro_or is add-on developer" -> "pir<image/>r is add-on developer"
These are big issue.
We can fix this issue with checking forward/backward empty string when replaces ascii art (ref. sample 3 in attachment):
work replaces case:
" o_o "
not work replace case:
"o_o"
However, as the result, "( o_o )" is replaced to ( <image/> ), so this is not solved.
There is many ascii art expression in the world.
Even if we ready the table for replacing them, we cannot encompass all expression of ascii art. So It's unreasonable to replace ascii art.
If we replace strings with image, we should use the replacing for fallback Unicode emoji on unsupported environment.
Ultimately, replacing any string/word is bad!
In the first place, this replacing behavior breaks the sentence if the expression "o_o" has meaning in a sentence.
Thus, I propose that we should DROP this replacing behavior from Tb-IM.
Comment 5•13 years ago
|
||
For RegExp, "\b" works as "boundary". I think it will help you to detect smiley patterns from text. It seems better than an empty string.
http://www.regular-expressions.info/wordboundaries.html
Comment 6•13 years ago
|
||
This seems to be the same bug as https://bugzilla.instantbird.org/show_bug.cgi?id=1139
It's not as simple as adding a \b though because people often put emoticons in a row: :):):), you'd still want to catch this situation.
Reporter | ||
Comment 7•13 years ago
|
||
The root problem of this bug is that a message client edits plain text without asking users.
Tb Instant Messaging treats some message services, for example IRC, Google chat, facebook chat, and Twitter. These services are provides plain text rather than markup test like markdown. Also user know & use it as plain text.
The replacing ascii art or text expression are useful on some case. But its case is for markup text. If a client replaces ascii art in text which is recognized as plain text by user, it confuses user.
Emoji introduced in Unicode 6.0. So we should uses them for expressing emotions as rich icon, and replace them for fallback on the environment which nonsupport unicode emoji.
Comment 8•13 years ago
|
||
I'd like to explain about emoticons in Japanese text.
First of all, most Japanese users don't use emoticons which are used in Western language users, e.g., ":-)". I think that it's caused by the difference of their culture. Japanese users prefer non-rotated emoticons like "(^_^)".
Secondary, as far as I know, there are no applications which replace the Japanese emoticons with images.
Therefore, for most Japanese users, it always occurs accidentally that a part of text is replaced with images.
I'm not sure whether Western language users like current behavior better. Even if they love the feature, I think that Tb should have following feature:
* Can enable/disable replacing emoticons with images by each kind of chat. E.g., can enable it for IRC but diable it for Twitter.
* Such prefs should be localizable.
I'm curious, do major twitter clients replace emoticons with images? Because the official web UI doesn't do it. So, I think that the replacing may occur accidentally for all users if they do it.
Comment 9•13 years ago
|
||
I would propose that TB adds some UI widget to refkect mail.display_glyph and lmessenger.options.emoticonsTheme status.
This could be done in Preferences/Composition/General and Preferences/Composition/Chat, or maybe both settings would be set by a single widget in Preferences/Composition/General (or any other pref panel that would fit better) ?
Maybe TB Japanese could have this setting turned off, and all other versions have it turned on ? This is probably better than turning it off because a specific locale has special requirements that is not found elsewhere.
Adding Blake for UX expertise
Comment 10•13 years ago
|
||
I find an actual problem. Some Japanese people uses (^^) and (^^;n
Tb only replaces ^^. So, other characters are stay and an image inserted between them.
Comment 12•11 years ago
|
||
In Finnish we use often :sta and :ssa.
:s is annoyingly replaced with a smiley.
For examples:
In mozilla.org = mozilla.org:ssa.
From TV = TV:sta.
This happens alot in Finnish language.
Updated•10 years ago
|
Component: Instant Messaging → General
Product: Thunderbird → Chat Core
Version: Trunk → trunk
Comment 13•10 years ago
|
||
It sounds to me like all these cases are handled in bug 954572.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•