Please, as it was discussed in length, could someone make the tool bar feature disabled by default.
This feature is broken. It does not work on many browsers. It should not be "on" per default for a newcomer. It is very disturbing.
Thanks
ant
On Feb 29, 2004, at 13:45, Anthere wrote:
Please, as it was discussed in length, could someone make the tool bar feature disabled by default.
The whole point is to be on by default for newcomers.
This feature is broken. It does not work on many browsers. It should not be "on" per default for a newcomer. It is very disturbing.
What's broken about it specifically that wasn't already addressed?
-- brion vibber (brion @ pobox.com)
Brion Vibber a écrit:
On Feb 29, 2004, at 13:45, Anthere wrote:
Please, as it was discussed in length, could someone make the tool bar feature disabled by default.
The whole point is to be on by default for newcomers.
But if it is on by default, and does not work for all, it will be *more disturbing* than beneficial to many users.
This feature is broken. It does not work on many browsers. It should not be "on" per default for a newcomer. It is very disturbing.
What's broken about it specifically that wasn't already addressed?
?!?!?
Look Brian...this was explained in length in numerous emails to that mailing list when the feature was discussed.
Some french people made a report of the browsers on which it is not working. It is here http://fr.wikipedia.org/wiki/Wikip%E9dia%3ABarre_d%27outils_d%27%E9dition
They reported it working on * Mozilla Firebird * Internet Explorer * Mozilla 1.6/W2K et XP Jyp 27 fév 2004 à 16:06 (CET)
and not working at all, or improperly on * Safari * Konqueror 3.1.5 * Konqueror 3.2. * Opera sous GNU/Linux * Opera 7.10 sous Windows * Mozilla 1.4 (KDE 3.1) elle apparaît et remplit ses fonctions mais fait des petits sauts de puce assez énervants. Fred.th
To which I am gonna add immediately Netscape which was obviously forgotten.
On Feb 29, 2004, at 14:32, Anthere wrote:
Brion Vibber a écrit:
On Feb 29, 2004, at 13:45, Anthere wrote:
Please, as it was discussed in length, could someone make the tool bar feature disabled by default.
The whole point is to be on by default for newcomers.
But if it is on by default, and does not work for all, it will be *more disturbing* than beneficial to many users.
We all agree 100% on this! That's why it's supposed to disable itself where it doesn't work. We bullied Erik into adding code to that SPECIFICALLY SO THAT IT WOULD NOT BREAK ON BROWSERS WHERE IT WOULD BREAK. Which brings us to:
This feature is broken. It does not work on many browsers. It should not be "on" per default for a newcomer. It is very disturbing.
What's broken about it specifically that wasn't already addressed?
?!?!?
Look Brian...this was explained in length in numerous emails to that mailing list when the feature was discussed.
Some french people made a report of the browsers on which it is not working. It is here http://fr.wikipedia.org/wiki/ Wikip%E9dia%3ABarre_d%27outils_d%27%E9dition
[snip]
Here's the results of my testing just now:
Win/IE 6.0: Works correctly in inline mode.
Mac/IE 5.2: Works correctly in infobox mode.
Konqueror 3.1.4: Works correctly in infobox mode.
Konqueror 3.2.0: Works correctly in infobox mode.
Win/Opera 7.23: Works correctly in infobox mode. When a button is clicked the browser does some sort of relayout which is distracting, but not as much as Opera 6.03. The edit box contents are not disturbed nor scrolled, but focus is lost. Minor usability issue.
Mac/Opera 6.03: Infobox mode seems to work but the screen scrolls up and down. Really really annoying.
Mozilla 1.2, Mozilla 1.6, Mozilla Firefox 0.8: Inline mode doesn't quite work: scrolls edit box to top. This is a serious usability problem. Erik was asked to use infobox mode for Mozilla because of this, but apparently never applied the fix. This should never have gotten out the door; I seem to remember Erik agreeing to fix this and am very surprised that it's not fixed as promised.
Safari 1.2: The "#" click incorrectly sends us to the bottom of the page; this is a serious usability problem. Otherwise seems to work correctly in infobox mode.
Netscape 4.77: Just doesn't work. No infobox, no inline.
-- brion vibber (brion @ pobox.com)
Brion-
Mozilla 1.2, Mozilla 1.6, Mozilla Firefox 0.8: Inline mode doesn't quite work: scrolls edit box to top.
This is a Mozilla bug: http://bugzilla.mozilla.org/show_bug.cgi?id=231389 It appears in all toolbars of this type. I prefer having this variant to the infobox variant -- once you press a cursor key you're back where you were before, so you can use the toolbar reasonably productively.
Netscape 4 probably uses the Moz code, needs some version checking in the JS.
Regards,
Erik
On Feb 29, 2004, at 15:34, Erik Moeller wrote:
Brion-
Mozilla 1.2, Mozilla 1.6, Mozilla Firefox 0.8: Inline mode doesn't quite work: scrolls edit box to top.
This is a Mozilla bug:
Yes, and we have to work around it.
http://bugzilla.mozilla.org/show_bug.cgi?id=231389 It appears in all toolbars of this type. I prefer having this variant to the infobox variant -- once you press a cursor key you're back where you were before, so you can use the toolbar reasonably productively.
Well, you're apparently at odds with the people who USE the wiki. I haven't heard a single consenting voice that says "yes! we should use the seriously broken mode, because someday Mozilla will work right with it and someday everyone using Mozilla will upgrade to that version!"
-- brion vibber (brion @ pobox.com)
Brion-
Well, you're apparently at odds with the people who USE the wiki. I haven't heard a single consenting voice that says "yes! we should use the seriously broken mode, because someday Mozilla will work right with it and someday everyone using Mozilla will upgrade to that version!"
My rationale is not that we should use it because it might work some day, but because it already works better than the infobox, in spite of the scrolling bug in Moz. I actively use the toolbar under Mozilla and would stop using it if it was in infobox mode.
However, I am thinking about implementing an alternative mode to the infobox which would use a javascript message-box to query for the text that is to be formatted. This would IMHO be more useful than the infobox and work in all browsers.
Regards,
Erik
Okay, I've updated the code. Changes include:
* On Mozilla-based browsers it now uses the infobox mode (where it has a box with example text rather than directly changing the main edit box and hitting the scroll bug, which isn't a problem for Erik but is a big problem for actual users). * I've changed the regular expression syntax to avoid causing a "Parse error!" message to pop up on every page view in old versions of Netscape (eg, 3.0). It still gives a runtime error when you edit a page in Netscape 3.0, but if you click 'ok' you can still edit. * It now does a better job at escaping apostrophe and quote characters in the tips and sample text. This was causing for instance the French "Cliquez sur un bouton pour obtenir un texte d'exemple" to cut off at the "d'".
I haven't yet solved the Safari scrolling problem, but it works ok if you make the window big enough that there's no room to scroll. :) It also only seems to trigger on long pages; if the edit box isn't full, it doesn't do it.
Haven't looked at Netscape 4 yet. I had the impression that it used to work in earlier testing, but could be wrong.
You may have to force reload the wikibits.js file to get things properly updated... eg http://fr.wikipedia.org/style/wikibits.js
-- brion vibber (brion @ pobox.com)
Can we have a per-language post-parser to be able to make language specific modification on text before rendering?
For example, in French typography, we need to put non-breaking space before characters ':', ';', '»', '!', '?', after '«' and between numbers hundreds.
Actually, we do that with HTML code but it make text sometime very ugly.
For exemple :
Il dit : « Bonjour ! »
Is actually write :
Il dit : « Bonjour ! »
I don't know if non-breaking space is used in other language typography?
An other solution may be to use a WikiSyntax for non-breaking space.
For example _ or __ to be convert to
The text above may become:
Il dit_: «_Bonjour !_»
Personally I prefer automatic conversion, and if you can make a hook after the WikiSyntax parse, I can do the PHP function that add non-breaking space where they must be.
Aoineko
On Mon, Mar 01, 2004 at 03:15:05PM +0900, Guillaume Blanchard wrote:
Can we have a per-language post-parser to be able to make language specific modification on text before rendering?
For example, in French typography, we need to put non-breaking space before characters ':', ';', '»', '!', '?', after '«' and between numbers hundreds.
Actually, we do that with HTML code but it make text sometime very ugly.
For exemple :
Il dit : « Bonjour ! »Is actually write :
Il dit : « Bonjour ! »I don't know if non-breaking space is used in other language typography?
An other solution may be to use a WikiSyntax for non-breaking space.
For example _ or __ to be convert to
The text above may become:
Il dit_: «_Bonjour !_»Personally I prefer automatic conversion, and if you can make a hook after the WikiSyntax parse, I can do the PHP function that add non-breaking space where they must be.
The idea sounds great, but it's very difficult to do right. Not everything on X Wikipedia is in language X - you have things in other languages, computer code, etc.
I think it would be nice to convert -- to real dash and _ to , but only if we can find good way for writing actual "--" and "_" when we want (and not only inside <pre> and <nowiki>). TeX-style _ would be absolutely the worst solution, and HTML-style &under; wouldn't be much better.
From: "Tomasz Wegrzanowski"
On Mon, Mar 01, 2004 at 03:15:05PM +0900, Guillaume Blanchard wrote:
Can we have a per-language post-parser to be able to make language
specific
modification on text before rendering?
For example, in French typography, we need to put non-breaking space
before
characters ':', ';', '»', '!', '?', after '«' and between numbers
hundreds.
Actually, we do that with HTML code but it make text sometime
very
ugly.
For exemple :
Il dit : « Bonjour ! »Is actually write :
Il dit : « Bonjour ! »I don't know if non-breaking space is used in other language typography?
An other solution may be to use a WikiSyntax for non-breaking space.
For example _ or __ to be convert to
The text above may become:
Il dit_: «_Bonjour !_»Personally I prefer automatic conversion, and if you can make a hook
after
the WikiSyntax parse, I can do the PHP function that add non-breaking
space
where they must be.
The idea sounds great, but it's very difficult to do right. Not everything on X Wikipedia is in language X - you have things in other
languages,
computer code, etc.
I think it would be nice to convert -- to real dash and _ to , but
only
if we can find good way for writing actual "--" and "_" when we want (and not only inside <pre> and <nowiki>). TeX-style _ would be absolutely the
worst
solution, and HTML-style &under; wouldn't be much better.
In my point of view, meta tag must be separate to the article text.
Convert '_' to is the simpler way, but I don't see any solution to solve the problem if this character is used in articles (I never see it in French article).
What about a post-parse function you may add in default language.php and that each language may derive to make language specific modification. For French, it may be very basic function: replace ' !' by ' !' and so on.
In fact, use '_' in instead of may make article more legible, but the problem is people may often forgot to put '_' in right place.
Aoineko
----
Render test
Actually:
Il dit : « Bonjour ! »
With '_' convert to
Il dit_: «_Bonjour_!_»
With post-parse process:
Il dit : « Bonjour ! »
On Mon, Mar 01, 2004 at 07:54:35PM +0900, Guillaume Blanchard wrote:
In my point of view, meta tag must be separate to the article text.
Convert '_' to is the simpler way, but I don't see any solution to solve the problem if this character is used in articles (I never see it in French article).
What about a post-parse function you may add in default language.php and that each language may derive to make language specific modification. For French, it may be very basic function: replace ' !' by ' !' and so on.
Never written article about programming ?
Tomasz Wegrzanowski wrote:
On Mon, Mar 01, 2004 at 07:54:35PM +0900, Guillaume Blanchard wrote:
What about a post-parse function you may add in default language.php and that each language may derive to make language specific modification. For French, it may be very basic function: replace ' !' by ' !' and so on.
Never written article about programming ?
Where would it ever matter to have a non-breaking space, which is visually indistinguishable from an ordinary space?
Tomasz Wegrzanowski wrote:
On Mon, Mar 01, 2004 at 07:54:35PM +0900, Guillaume Blanchard wrote:
What about a post-parse function you may add in default language.php and that each language may derive to make language specific modification.
For
French, it may be very basic function: replace ' !' by ' !' and so
on.
Never written article about programming ?
Where would it ever matter to have a non-breaking space, which is visually indistinguishable from an ordinary space?
In French typography, a non-breaking space must be place before sign like [:] so that a line break (caused by display width fit) never occur between [:] and the preceding word. It's same for [;], [!], [?], [«] and [»]. And for numbers, each hundred must also be separated with non-breaking space. The simple way I see to do that is to write article with normal space (0x13) then convert them (when necessary) to before render the page. It may be easily done after Wiki-syntax parsing by remplacing pair of characters (ex: [0x13][:] => [ ][:]).
Aoineko
What about me request ? Can you add a hook at the end of parsing process that other language can make language specific parsing ?
Aoineko
Never written article about programming ?
Where would it ever matter to have a non-breaking space, which is visually indistinguishable from an ordinary space?
In French typography, a non-breaking space must be place before sign like [:] so that a line break (caused by display width fit) never occur between [:] and the preceding word. It's same for [;], [!], [?], [«] and [»]. And for numbers, each hundred must also be separated with non-breaking space. The simple way I see to do that is to write article with normal space
(0x13)
then convert them (when necessary) to before render the page. It
may
be easily done after Wiki-syntax parsing by remplacing pair of characters (ex: [0x13][:] => [ ][:]).
Aoineko
Guillaume Blanchard wrote:
Timwi wrote:
Where would it ever matter to have a non-breaking space, which is visually indistinguishable from an ordinary space?
In French typography, [...]
I know all that. That's not what I asked.
Guillaume Blanchard wrote:
Timwi wrote:
Where would it ever matter to have a non-breaking space, which is visually indistinguishable from an ordinary space?
In French typography, [...]
I know all that. That's not what I asked.
Ok, let's try a better exemple. (please look it with a proportional font)
'_' is non-breaking space. ' ' is normal space. '|' is line break location. Here is a text: 'Il dit : « 10 000 fois bonjour ! »'.
With "normal" space:
Il dit : « 10| 000 fois bonjour| ! »
may be displayed as:
| Il dit : « 10 | | 000 fois bonjour | | ! » |
...that is incorrect in French typography. With non-breaking space:
Il dit_: «_10|_000 fois bonjour|_!_»
may be displayed as:
| Il dit_: | | «_10_000 fois | | bonjour_!_» |
... that is correct. Do you understand the problem ?
Aoineko
On Tue, Mar 02, 2004 at 07:22:56PM +0900, Guillaume Blanchard wrote:
Ok, let's try a better exemple. (please look it with a proportional font)
'_' is non-breaking space. ' ' is normal space. '|' is line break location. Here is a text: 'Il dit : ? 10 000 fois bonjour ! ?'.
With "normal" space:
Il dit : ? 10| 000 fois bonjour| ! ?
may be displayed as:
| Il dit : ? 10 | | 000 fois bonjour | | ! ? |
...that is incorrect in French typography. With non-breaking space:
Il dit_: ?_10|_000 fois bonjour|_!_?
may be displayed as:
| Il dit_: | | ?_10_000 fois | | bonjour_!_? |
... that is correct. Do you understand the problem ?
Committed code change to CVS. Please test at http://jeluf.mormo.org/testwiki/wiki.phtml?title=Bonjour
Regards,
JeLuF
Guillaume Blanchard wrote:
Guillaume Blanchard wrote:
Timwi wrote:
Where would it ever matter to have a non-breaking space, which is visually indistinguishable from an ordinary space?
In French typography, [...]
I know all that. That's not what I asked.
Ok, let's try a better exemple. (please look it with a proportional font)
[...]
I know all of that. That still has nothing to do with what I asked.
Timwi wrote:
Guillaume Blanchard wrote:
Timwi wrote:
Where would it ever matter to have a non-breaking space, which is visually indistinguishable from an ordinary space?
In French typography, [...]
I know all that. That's not what I asked.
Does it make any difference in article titles?
Ec
From: "Ray Saintonge"
Does it make any difference in article titles?
Yes, in rare case of a title is long enough to be line broke and use a character that need non-breaking space.
From: "Jens Frank"
Committed code change to CVS. Please test at http://jeluf.mormo.org/testwiki/wiki.phtml?title=Bonjour
Perfect!! Merci beaucoup!
This code change may be specific for fr: or common to all Wikipedia?
From: "Timwi"
Where would it ever matter to have a non-breaking space, which is
I know all of that. That still has nothing to do with what I asked.
What obviously I don't understand your question, could you reformulate it?
Aoineko
On Mon, Mar 01, 2004 at 03:41:15PM +0000, Timwi wrote:
Tomasz Wegrzanowski wrote:
On Mon, Mar 01, 2004 at 07:54:35PM +0900, Guillaume Blanchard wrote:
What about a post-parse function you may add in default language.php and that each language may derive to make language specific modification. For French, it may be very basic function: replace ' !' by ' !' and so on.
Never written article about programming ?
Where would it ever matter to have a non-breaking space, which is visually indistinguishable from an ordinary space?
Uhm, it would matter to have "_" character available, so we can't just s/_/&nbsb;/g.
Tomasz Wegrzanowski wrote:
On Mon, Mar 01, 2004 at 03:41:15PM +0000, Timwi wrote:
Tomasz Wegrzanowski wrote:
On Mon, Mar 01, 2004 at 07:54:35PM +0900, Guillaume Blanchard wrote:
What about a post-parse function you may add in default language.php and that each language may derive to make language specific modification. For French, it may be very basic function: replace ' !' by ' !' and so on.
Never written article about programming ?
Where would it ever matter to have a non-breaking space, which is visually indistinguishable from an ordinary space?
Uhm, it would matter to have "_" character available, so we can't just s/_/&nbsb;/g.
Right. Of course, that makes sense. The "_" character must be typable (and easier than <nowiki>_</nowiki>).
My suggestion would have been to require __ (two underscores) for one . Since two underscores occur rarely in "reality", it probably would be OK to require <nowiki>__</nowiki> should they really ever come up.
--- Tomasz Wegrzanowski taw@users.sf.net wrote:
On Mon, Mar 01, 2004 at 03:15:05PM +0900, Guillaume Blanchard wrote:
Can we have a per-language post-parser to be able
to make language specific
modification on text before rendering?
For example, in French typography, we need to put
non-breaking space before
characters ':', ';', '�', '!', '?', after '�' and
between numbers hundreds.
Actually, we do that with HTML code but it
make text sometime very
ugly.
For exemple :
Il dit : � Bonjour ! �Is actually write :
Il dit : � Bonjour ! �I don't know if non-breaking space is used in
other language typography?
An other solution may be to use a WikiSyntax for
non-breaking space.
For example _ or __ to be convert to
The text above may become:
Il dit_: �_Bonjour !_�Personally I prefer automatic conversion, and if
you can make a hook after
the WikiSyntax parse, I can do the PHP function
that add non-breaking space
where they must be.
The idea sounds great, but it's very difficult to do right. Not everything on X Wikipedia is in language X - you have things in other languages, computer code, etc.
I think it would be nice to convert -- to real dash and _ to , but only if we can find good way for writing actual "--" and "_" when we want (and not only inside <pre> and <nowiki>). TeX-style _ would be absolutely the worst solution, and HTML-style &under; wouldn't be much better.
Along the same lines, I was wondering if such a pre-parser could be used to address the issue of browsers that break non-ascii characters when editing. For such a browser, non-ascii characters could be converted into numeric code equivalents (or html code, eg. —) before presented for editing, and then converted back after editing.
__________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools
On Mon, 2004-03-01 at 02:06, Tomasz Wegrzanowski wrote:
On Mon, Mar 01, 2004 at 03:15:05PM +0900, Guillaume Blanchard wrote:
Can we have a per-language post-parser to be able to make language specific modification on text before rendering?
For example, in French typography, we need to put non-breaking space before characters ':', ';', '»', '!', '?', after '«' and between numbers hundreds.
Actually, we do that with HTML code but it make text sometime very ugly.
For exemple :
Il dit : « Bonjour ! »Is actually write :
Il dit : « Bonjour ! »I don't know if non-breaking space is used in other language typography?
The idea sounds great, but it's very difficult to do right. Not everything on X Wikipedia is in language X - you have things in other languages, computer code, etc.
Does this really matter? It doesn't seem like other languages, or computer code, would be hurt by changing a few spaces to non-breaking spaces.
Carl Witty
"Guillaume Blanchard" gblanchard@arcsy.co.jp writes:
For exemple :
Il dit : « Bonjour ! »
It looks very odd when viewed on a monospaced terminal. The space it much too large.
Is actually write :
Il dit : « Bonjour ! »
This also is pretty wrong, conceptually. All what is needed, is to issue a "lang" resp. "xml:lang" attribute and then leave it to the rendering engine to do the right thing. The "lang" is there, and now start complaining to the browser vendors :)
TeX/LaTeX in combination with babel is one of the formatters which gets it right.
The worst thing you can do, is to clutter the text with even more special caracters
But if it is on by default, and does not work for all, it will be *more disturbing* than beneficial to many users.
We all agree 100% on this! That's why it's supposed to disable itself where it doesn't work. We bullied Erik into adding code to that SPECIFICALLY SO THAT IT WOULD NOT BREAK ON BROWSERS WHERE IT WOULD BREAK.
Ben... at least on mine, it is not disabled by default :-( perhaps my browser type was forgotten in the controls ?
Here's the results of my testing just now:
Win/IE 6.0: Works correctly in inline mode.
Mac/IE 5.2: Works correctly in infobox mode.
Konqueror 3.1.4: Works correctly in infobox mode.
Konqueror 3.2.0: Works correctly in infobox mode.
Win/Opera 7.23: Works correctly in infobox mode. When a button is clicked the browser does some sort of relayout which is distracting, but not as much as Opera 6.03. The edit box contents are not disturbed nor scrolled, but focus is lost. Minor usability issue.
Mac/Opera 6.03: Infobox mode seems to work but the screen scrolls up and down. Really really annoying.
Mozilla 1.2, Mozilla 1.6, Mozilla Firefox 0.8: Inline mode doesn't quite work: scrolls edit box to top. This is a serious usability problem. Erik was asked to use infobox mode for Mozilla because of this, but apparently never applied the fix. This should never have gotten out the door; I seem to remember Erik agreeing to fix this and am very surprised that it's not fixed as promised.
Safari 1.2: The "#" click incorrectly sends us to the bottom of the page; this is a serious usability problem. Otherwise seems to work correctly in infobox mode.
Netscape 4.77: Just doesn't work. No infobox, no inline.
-- brion vibber (brion @ pobox.com)
:-( Well, I'll copy these tests in our discussion page... What else to say :-(
thanks for the test Brion. I notice some of your positive tests are mentionned negative on fr ?
wikitech-l@lists.wikimedia.org