Talk:Browser issues with MediaWiki

I'm not sure about Lynx. Is it "UTF-8 safe" ?


 * If you configure the character encoding to "UNICODE (UTF-8)" in the options, then yes. However, unless you're running in a UTF-8 terminal your display may suck. (Note that xterm has a utf-8 mode (option -u8 or something) that you can use if you're not running in a UTF-8 locale. For the linux console, run 'unicode_start' to put the console into UTF-8 mode. For others, I don't know offhand.) --Brion VIBBER 07:18 Oct 19, 2002 (UTC)
 * Thanks for your explanation. So my Lynx was probably the culprit that screwed up a few pages. Sorry. Anyway I quite like Lynx. --Kpjas


 * Also you might give Links a try; it's quite nice. It's basically a text-mode browser which but has a hopped-up graphics mode which is still comfortably lightweight. In text mode it seems to have the same troubles as lynx (by default it converts the edit box contents to the locale charset, breaking characters outside that range), but in graphics mode it handles Unicode well. --Brion VIBBER 21:07 Oct 19, 2002 (UTC)

-- Would it be possible to place a UTC time and date stamp in the text area for each Recent Changes? I often find it confusing to try sync my home time zone time with sig times which are in UTC. --mav


 * You mean like a 'Current server time is XX:XX:XX'? --Brion VIBBER 07:29 Oct 27, 2002 (UTC)


 * Yup. The date would also be good to have. BTW, is there something akin to automatic date stamps for time? Example: Tuesday August 27, 2024 -> Tuesday August 27, 2024. But doesn't work. --mav


 * It does now. Yippee! I'm planning to make the Recentchanges header text editable again by hook or by crook; the timestamps can be easily plunked in then. --Brion VIBBER 14:07 Oct 27, 2002 (UTC)


 * Cool. Thanks again Brion! :) --mav

Ordered / Unordered Lists randomly breaking Save form??
Observed with Firefox 1.0.2 and Safari 1.2.4 on MediaWiki 1.4.0:

Upon hitting Save, I get a 404 error, and it says that the index.php file is the one it cannot find. Which of course is not true, it's there, and it finds it fine. Systematically removing parts of the text I'm trying to add word by word revealed that both ordered and unordered lists can cause the problem, but it seems completely random.

Small lists will do it, and the "breaking point" can be a couple of words into one particular bullet.

For instance:


 * Drag and drop your source video file into the "From" area on the left in ffmpegX's summary tab
 * Select PSP from the Target area dropdown menu
 * If desired, adjust the bitrate for the video and audio under the respective tabs. Take care to not  hange other settings, or your video will be unplayable by the PSP video player.
 * Click "Encode"

Generates the 404 error upon saving, but removing one word at a time might reveals that:


 * Drag and drop your source video file into the "From" area on the left in ffmpegX's summary tab
 * Select PSP

posts just fine.

What could possibly be causing this problem? It seems like a problem with the form data processing, but it's not even breaking on a tag--it's just mid-sentence--so I'm stumped. And of course it works here, though I don't know what version this site is running on.

[Edit: Changing the word "Select" while keeping the rest of the text also allows it to post. I think the parser is trying to use the Select function from PHP?]