Last modified: 2010-12-04 22:42:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5401, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3401 - Dealing with non unicode aware browsers part 2
Dealing with non unicode aware browsers part 2
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: High major with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: unicode
  Show dependency treegraph
Reported: 2005-09-08 22:20 UTC by peter green
Modified: 2010-12-04 22:42 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

client-side workaround . (344 bytes, text/plain)
2009-06-12 22:26 UTC, Steen

Description peter green 2005-09-08 22:20:07 UTC
the resoloution to 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.
  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 

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.
Comment 1 Steen 2009-06-12 22:26:20 UTC
Created attachment 6222 [details]
client-side workaround .

Python3 script . Recommended use : Lynx session, external editor vim, :.,$!cat % | ./ .
Comment 2 Steen 2009-06-12 22:38:31 UTC
Comment on attachment 6222 [details]
client-side workaround .

from vim
:.,$!cat % |
Comment 3 peter green 2010-07-29 00:25:26 UTC
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.
Comment 4 DieBuche 2010-12-04 22:42:08 UTC
see above comment

Note You need to log in before you can comment on or make changes to this bug.