While checking out browser issues on mediawiki due to bad edits like
http://en.wikipedia.org/w/index.php?title=Star_Wars_Episode_III:_Revenge_of_
the_Sith&diff=prev&oldid=21694074 it was brought to my attention that lynx
and links were problematic. additional research has shown that w3m also
suffers from this issue in a way that is in some ways more problematic than
how the other browsers suffer. w3m only breaks the edit box text if you
actually edit it meaning its not possible to use say a dummy edit box at
login time to detect if it is in a unicode safe mode.
The issue seems to be that all the browserts listed convert the text to the
users local character set before editing and then convert it back to utf-8
for submission. This leads to breakage of parts of the text that the user
did not intend to edit. This is a major issue for sites like wikis where
browsers are used to edit existing text.
we do have a workaround in place
(
http://bugzilla.wikimedia.org/show_bug.cgi?id=2676) for IE mac (where there
is no hope of a fix) and this workaround could be extended to the text based
browsers listed. However i'm reluctant to submit a patch to do that as
afaict all of the aformentioned browsers do have modes in which they can
edit unicode safely. Unfortunately it doesn't seem possible to detect when
they are in such modes. I'm writing this message to ask two questions 1: are
there any ways of detecting if a text browser is safe to edit unicode from
the requests it makes (i couldn't find any) and if not would you be prepared
to agree on a method for indicating you are in a mode that is safe for
editing unicode in future versions of your browsers (possiblly by sending
accept-charset headers with weighting based on the mode).