The "save page" issue gave me the idea that we could submit an official input from the WMF to the Mozilla Foundation on 10 key issues that affect users of MediaWiki (an thereby, WMF). We have a fairly good relationship with Mozilla & I think they'd be willing to give these issues some priority if we ask nicely. A quick search on bugzilla.mozilla.org suggests there are plenty of issues; if someone wants to take the lead on this, I've started a stub here:
http://meta.wikimedia.org/wiki/Top_10_Firefox_bugs
On 4/2/07, Erik Moeller erik@wikimedia.org wrote:
The "save page" issue gave me the idea that we could submit an official input from the WMF to the Mozilla Foundation on 10 key issues that affect users of MediaWiki (an thereby, WMF). We have a fairly good relationship with Mozilla & I think they'd be willing to give these issues some priority if we ask nicely. A quick search on bugzilla.mozilla.org suggests there are plenty of issues; if someone wants to take the lead on this, I've started a stub here:
Nice idea; maintaining a list of commonly encountered bugs on wiki should help reduce the number of dups raised on b.m.o (see Bug 372474) by wiki users.
-- John
The "save page" issue gave me the idea that we could submit an official input from the WMF to the Mozilla Foundation on 10 key issues that affect users of MediaWiki (an thereby, WMF). We have a fairly good relationship with Mozilla & I think they'd be willing to give these issues some priority if we ask nicely. A quick search on bugzilla.mozilla.org suggests there are plenty of issues; if someone wants to take the lead on this, I've started a stub here:
I did a quick search on Mozilla's bugzilla - restricted to bugs logged against Firefox, and that are UNCONFIRMED / NEW / ASSIGNED / REOPENED / VERIFIED [i.e. not RESOLVED or CLOSED], and where any comment contains the word "wikipedia", and where it has more than 2 votes [to cut out the stuff that's not impacting too many people].
That gives 17 bugs: http://tinyurl.com/34qsov
Scanning quickly through those gives some issues which look to no longer affect the wikipedia, some which are specific to Linux and where the Wikipedia is just used as an example, some that include a Wikipedia article as a reference, etc.
Probably the one that most seemed like a potential for the list was https://bugzilla.mozilla.org/show_bug.cgi?id=366797 ( Revise the Location Bar ) which seems to cover not showing unreadable URLs in the address bar, like: http://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%9... ... and instead showing stuff like: http://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%9... (and if that URL gets mangled by some email software, it was a 9 letter Ukrainian word, written in a non-ASCII alphabet). But the point is, if you spoke Ukrainian, you could probably read the second version, versus having no hope of reading the urlencoded version. Of course, there are security concerns about non-ASCII alphabets that contain characters that look similar to ASCII ones, especially in the domain name portion, but presumably these can be resolved somehow (e.g. there's something similar in operation now I think for detecting very similar looking Wikipedia usernames, including using non-ASCII chars).
All the best, Nick.
2007/4/2, Nick Jenkins nickpj@gmail.com:
Probably the one that most seemed like a potential for the list was https://bugzilla.mozilla.org/show_bug.cgi?id=366797 ( Revise the Location Bar ) which seems to cover not showing unreadable URLs in the address bar, like:
http://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%9... ... and instead showing stuff like: http://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%9... (and if that URL gets mangled by some email software, it was a 9 letter Ukrainian word, written in a non-ASCII alphabet). But the point is, if you spoke Ukrainian, you could probably read the second version, versus having no hope of reading the urlencoded version. Of course, there are security concerns about non-ASCII alphabets that contain characters that look similar to ASCII ones, especially in the domain name portion, but presumably these can be resolved somehow (e.g. there's something similar in operation now I think for detecting very similar looking Wikipedia usernames, including using non-ASCII chars).
To be honest, from my point of view, as a bot operator/programmer, I am quite happy with this bug. If I want to tell the bot that I have to link to [[uk:Вікіпедія]], I can give it [[uk:%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%96%D1%8F]], which is a bug to type, but at least possible. With the command tool in Windows not allowing cut-and-paste, I cannot give it any characters that are not on my normal keyboard in another way.
Andre Engels wrote:
With the command tool in Windows not allowing cut-and-paste, I cannot give it any characters that are not on
my
normal keyboard in another way.
"command tool" == cmd.exe?
try the context menu on the window's icon...
-- chris
To be honest, from my point of view, as a bot operator/programmer, I am quite happy with this bug.
But for folks using Wikipedia in Russian, Ukrainian, Belarus, Bulgarian, Serbian, it is ugly.
Example,
http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B...
is Main Page URL. Do you want to type it?
See http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier
With the command tool in Windows not allowing cut-and-paste
It is possible. Try to use menu in top left angle of window
-- Amike kaj kunlabore, Aleks
2007/4/2, Александр Сигачёв alexander.sigachov@gmail.com:
To be honest, from my point of view, as a bot operator/programmer, I am quite happy with this bug.
But for folks using Wikipedia in Russian, Ukrainian, Belarus, Bulgarian, Serbian, it is ugly.
I agree. The fact that people like me are using the bug doesn't mean it's not a bug.
Example,
http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B...
is Main Page URL. Do you want to type it?
It's just about the edge - smaller ones I do type, for larger ones I create the page [[Участник:Robbot/Temp]] with a redirect to the page I want to have.
With the command tool in Windows not allowing cut-and-paste
It is possible. Try to use menu in top left angle of window
Thanks, I did not know that one.
Andre Engels wrote:
2007/4/2, Александр Сигачёв alexander.sigachov@gmail.com:
To be honest, from my point of view, as a bot operator/programmer, I am quite happy with this bug.
But for folks using Wikipedia in Russian, Ukrainian, Belarus, Bulgarian, Serbian, it is ugly.
I agree. The fact that people like me are using the bug doesn't mean it's not a bug.
Example,
http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B...
is Main Page URL. Do you want to type it?
It's just about the edge - smaller ones I do type, for larger ones I create the page [[Участник:Robbot/Temp]] with a redirect to the page I want to have.
With the command tool in Windows not allowing cut-and-paste
It is possible. Try to use menu in top left angle of window
Thanks, I did not know that one.
I surely hope that this bug gets fixed..it is very annoying!
On the other end, I need it for the bot as you Angels.. you can use this [1] after it is fixed ;)...
[1] http://netzreport.googlepages.com/online_tool_for_url_en_decoding.html
Mohamed~alnokta
Александр Сигачёв wrote:
To be honest, from my point of view, as a bot operator/programmer, I am quite happy with this bug.
But for folks using Wikipedia in Russian, Ukrainian, Belarus, Bulgarian, Serbian, it is ugly.
Example,
http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B...
is Main Page URL. Do you want to type it?
Then simply type http://ru.wikipedia.org/
The non-escaped title is always at the top of the page. Also note that on the status bar the unescaped version is shown (when you see where will a link send you), probably a great improvement.
While i agree showing the full name on the URL is much nicer when you see the URL (eg. on a printed article), it leaves the door open for abuse and impersonators, as you don't have a way to detect the difference between the users (now you can go to their user page and see the URL). I was once confused because assumed the satus bar would give me the escaped one. If the URL is also 'niced', how to tell?
Another thing to take into account is how would url-editing work. Currently, if i write the url in non-utf8 characters (like the common Windows-1252), it's detected as not utf8, the non US-Ascii ones gets escaped and i get to the desired page. If i reedit the escaped url adding non-utf8 chars, the whole url is treated as not being in utf8, so the already-utf8 characters are treated as native and reencoded... landing on the wrong page. You can avoid this by rewriting the %xx with your encoding, but if you can't see the difference, what will you do when users get to a page title full of à when they didn't typed that?
Platonides
Александр Сигачёв wrote:
To be honest, from my point of view, as a bot operator/programmer, I am quite happy with this bug.
But for folks using Wikipedia in Russian, Ukrainian, Belarus, Bulgarian, Serbian, it is ugly.
BTW, there's an extension "Human URL" that solves an issue.
http://www.outraged-artists.com/flockd/profile.php?name=Human+URL
http://www.google.com/search?q=Human%20URL
Nick Jenkins wrote:
Probably the one that most seemed like a potential for the list was https://bugzilla.mozilla.org/show_bug.cgi?id=366797 ( Revise the Location Bar ) which seems to cover not showing unreadable URLs in the address bar, like: http://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%9... ... and instead showing stuff like: http://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%9... (and if that URL gets mangled by some email software, it was a 9 letter Ukrainian word, written in a non-ASCII alphabet). But the point is, if you spoke Ukrainian, you could probably read the second version, versus having no hope of reading the urlencoded version. Of course, there are security concerns about non-ASCII alphabets that contain characters that look similar to ASCII ones, especially in the domain name portion, but presumably these can be resolved somehow (e.g. there's something similar in operation now I think for detecting very similar looking Wikipedia usernames, including using non-ASCII chars).
All the best, Nick.
Work on the menu-bar display issue is part of a more general reworking of some of the IRI / IDN -handling internals of Firefox/Gecko: I'm involved in some of this...
-- Neil
On 4/2/07, Nick Jenkins nickpj@gmail.com wrote:
I did a quick search on Mozilla's bugzilla - restricted to bugs logged against Firefox . . .
Probably the bugs logged against Core (layout, etc.) are at least as important. Like https://bugzilla.mozilla.org/show_bug.cgi?id=218277, now fixed. Some bugs that are worth considering: 50630, 60307, 365970, 372462. But those are really more general wishlist-type things regarding layout that would benefit pretty much everyone. I don't think many of these bugs are really important to Wikipedia specifically, except that one i18n issue and maybe the few "save page as" ones. Perhaps a list of five would be better than one of ten.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Monday 02 April 2007 06:20:37 Erik Moeller wrote:
The "save page" issue gave me the idea that we could submit an official input from the WMF to the Mozilla Foundation on 10 key issues that affect users of MediaWiki (an thereby, WMF). We have a fairly good relationship with Mozilla & I think they'd be willing to give these issues some priority if we ask nicely. A quick search on bugzilla.mozilla.org suggests there are plenty of issues; if someone wants to take the lead on this, I've started a stub here:
The TOP bug for me are the button/login bars on the top. With old Firefox, the buttons "edit", "move" etc. where on the same line with the "login" button (if horizontal space permitted it). Now the "login link" is on it's own line, focing the other buttons down. This wastes just screenspace, which is important for small screens, like laptops; esp. if you have a widescreen laptop - because there is enough space for both bars horizontally aligned, but less space vertically.
All the best,
Tels
- -- Signed on Mon Apr 2 13:13:17 2007 with key 0x93B84C15. View my photo gallery: http://bloodgate.com/photos PGP key on http://bloodgate.com/tels.asc or per email.
"Step 7: Alpha release ... * Scheduled: June 2001"
-- Damian Conway's Perl 6 Update (February 2001)
"Tels" nospam-abuse@bloodgate.com wrote in message news:200704021316.53086@bloodgate.com...
The TOP bug for me are the button/login bars on the top. With old Firefox, the buttons "edit", "move" etc. where on the same line with the "login" button (if horizontal space permitted it). Now the "login link" is on it's own line, focing the other buttons down. This wastes just screenspace, which is important for small screens, like laptops; esp. if you have a widescreen laptop - because there is enough space for both bars horizontally aligned, but less space vertically.
Is that a Firefox bug, or just a change in the MW CSS? Have you tried old versions of MW in the newest version of Firefox, or vice versa?
- Mark Clements (HappyDog)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Monday 02 April 2007 11:20:53 Mark Clements wrote:
"Tels" nospam-abuse@bloodgate.com wrote in message news:200704021316.53086@bloodgate.com...
The TOP bug for me are the button/login bars on the top. With old Firefox, the buttons "edit", "move" etc. where on the same line with the "login" button (if horizontal space permitted it). Now the "login link" is on it's own line, focing the other buttons down. This wastes just screenspace, which is important for small screens, like laptops; esp. if you have a widescreen laptop - because there is enough space for both bars horizontally aligned, but less space vertically.
Is that a Firefox bug, or just a change in the MW CSS? Have you tried old versions of MW in the newest version of Firefox, or vice versa?
Not recently, but I noticed the change after upgrading Firefox (some years back). I also build a website that relied on that effect (the two bars next to each other) and upgrading Firefox "broke" this.
Konqueror did it right, back then. A quick check with current Konqueror and current Opera now shows all of them rendering it the same, "wrong" way. So maybe the CSS is just "wrong", and the browsers show it correctly. However, I am no expert in CSS so cannot decide this :)
All the best,
Tels
- -- Signed on Mon Apr 2 13:58:59 2007 with key 0x93B84C15. View my photo gallery: http://bloodgate.com/photos PGP key on http://bloodgate.com/tels.asc or per email.
"The need for a Steam account to play HL2 is like having to login to MS Passport to play Minesweeper."
-- Tels
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tels wrote:
The TOP bug for me are the button/login bars on the top. With old Firefox, the buttons "edit", "move" etc. where on the same line with the "login" button (if horizontal space permitted it). Now the "login link" is on it's own line, focing the other buttons down.
I just checked in Firefox 1.0.8; it looks *exactly* the same as 1.5.0.7 and 2.0.0.3. Can you clarify how old a Firefox you mean?
- -- brion vibber (brion @ wikimedia.org)
wikitech-l@lists.wikimedia.org