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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3401 - Dealing with non unicode aware browsers part 2
Dealing with non unicode aware browsers part 2
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.6.x
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: ---


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

Description peter green 2005-09-08 22:20:07 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.
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 % | ./chr.wiki.py .
Comment 2 Steen 2009-06-12 22:38:31 UTC
Comment on attachment 6222 [details]
client-side workaround .

from vim
:.,$!cat % | chr.wiki.py
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.


Navigation
Links