Last modified: 2010-12-04 22:42:08 UTC
the resoloution to http://bugzilla.wikimedia.org/show_bug.cgi?id=2676 dealt with the IE mac which it seems was more of a problem than all the others combined. However I'm still getting sporadic reports of problems. and some of them are more complex cases than IE mac was ;) netscape 4.x unable to edit unicode properly on any platform i've tried it on. The difficulty here is making a regexp to identify all subversions of it without matching stuff that declares itself as compatible with it lynx and links these convert to the local charset (links apparently only when in text mode) if the local charset is utf-8 then they are fine if it isn't they currupt unicode. w3m similar to lynx and links but doesn't currupt the text until its actually edited meaning dummy edit boxes can't be used to identify if its in a problem mode. I also have a strange bad edit report for which the browser has not yet been identified see http://en.wikipedia.org/w/index.php?title=Saint_Cyril&diff=prev&oldid=22770191 Ideas on how to proceed. allow users to manually enable and disable safe mode editing in preferences (with default being to base on blacklist). for lynx and links detect by a dummy edit control on login form add netscape4 and w3m to blacklist any comments on these ideas welcome.
Created attachment 6222 [details] client-side workaround . Python3 script . Recommended use : Lynx session, external editor vim, :.,$!cat % | ./chr.wiki.py .
Comment on attachment 6222 [details] client-side workaround . from vim :.,$!cat % | chr.wiki.py
netscape 4.x was added to the blacklist some time ago. The other browsers don't seem to be causing any problems in practice (I guess the number of users trying to edit from text mode on non utf-8 unix systems is minimal) so this can probablly be closed.
see above comment
