Re: Re: tool bar

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  <at>  pobox.com)

_______________________________________________

post-parser for language specific modification

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.

Re: Parser implementation submitted to HEAD

Jens Frank wrote:

>On Sun, Feb 29, 2004 at 12:17:42PM +0100, Magnus Manske wrote:
>  
>
>>Jens Frank wrote:
>>    
>>
>>>Hi,
>>>
>>>a new parser for internal links [[...]] and ''quotes''
>>>has been committed to cvs HEAD. 
>>>      
>>>
>>Cool, but it appears to have killed the category feature I revived in 
>>HEAD a few days ago. I'll try to fix that today.
>>    
>>
>
>How can I test this feature? What does it do? 
>  
>
It's supposed to work like this:
1. Set "$wgUseCategoryMagic = true" in settings
2. Write "[[category:Stuff]]" in an article (say, [[xyz]])
3. "Categories: Stuff" (with link to [[Category:Stuff]]) will appear as 
first line in the article
4. On [[Category:Stuff]] (save a summy text there) all articles that 
link to that category (in this case, [[xyz]]) will be listed

Re: Bug tracker

Ivan Krstic wrote:

> Brion Vibber wrote:
> 
>> If someone would like to commit to being Keeper of the WikiBugs and 
>> herd the necessary cats, then I'm all in favor of giving it a try.
> 
> I might be willing to take this on; I'd just like a sound understanding 
> of what cats you're specifically referring to herding. Other than the 
> keeptrack-assign-verify-close process, what else do you feel would need 
> to be done?

Some of the almost essential features of BugZilla include:
* Severity and/or priority
* Keywords (every BugZilla installation has a pre-defined set of them)
* Status (unconfirmed, new, assigned, resolved, verified, closed)
* Resolution (if the status is "resolved", was it "fixed", "invalid",
   "duplicate" (if so, of what other bug), "wontfix", "worksforme", etc.)
* SEARCHING! Searching for combinations of all of these criteria, plus
   when a bug was last changed, when it was opened, by who, etc.etc.

Some of the not-so-essential-but-highly-useful features:
* CC lists. (Getting e-mailed with every change to a bug.)
* Even more SEARCHING! Complex queries for highly specific purposes.

I can't think of more for now, but there's probably more 

I can see all of these implementable in a Wiki (with e-mail CC lists 
replaced by watchlists), EXCEPT FOR SEARCHING. Unfortunately, searching 
is the most important of all. This is why I don't think it's feasible to 

Re: identification

Angela wrote:

> This is so you can have half of the login message
> below the login box if you want to. If you don't want
> it, 
> just replace "<loginend>" with " " at
> http://fr.wikipedia.org/w/wiki.phtml?title=MediaWiki:Loginend.

Does it need an   at all? 

Separating article and meta-content

I believe we need to start thinking about ways to better separate content  
and metadata. Making them editable separately, and perhaps making either  
type of content filterable, gives us room for expansion in the meta realm  
without impacting editability for users who just want the plain text.

Current meta-tags:
* interlanguage links
* __NOTOC__
* __NOEDITSECTION__
* category links (experimental)

Possible future meta-tags:
* <editnote> - shown on top of the edit box during editing, e.g. "Please  
describe new events in the present tense"
* <sizelimit> - for auto-archiving or size warnings
* __NOCACHE__
* __NOTITLE__, __NOSUBTITLE__ for navigational pages, Main Page
* [[Edition=Print]] and other name=value tags
* .. anything else that would be useful, but clutter on the article page

I see two possibilities, one of which I call the hackish approach and the  
other the clean approach.

== The hackish approach ==

Add a new tag, called <meta>. Content within <meta>..</meta> is shown in a  
separate window, like this:

<pre>
 _________________________________________

Cache stress-testing

Word on the street is that load's going to be extra high today thanks 
to some print exposure in Germany. I've taken the occasion to 
stress-test Coronelli running its cache server under 2.6... Browne 
(which was carrying all wikis but English) was starting to have its 
periodic freezes, and at least one squid crash. I switched the .235 
address over to Coronelli, so it's now handling _all_ incoming traffic.

So far it seems to be handling it smoothly; I'm not seeing the freezes 
that browne had. We can switch one or both addresses back to browne if 
needed.

[brion@... brion]$ uptime
  09:57:36 up 2 days,  7:25,  8 users,  load average: 1.66, 1.78, 1.23

Some vmstat fragments:
procs -----------memory---------- ---swap-- -----io---- --system-- 
----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us 
sy id wa
  2  1   9996   8128 151056 884652   21    0   107   591 1358   294 13 
42 35 10
  1  0   9996   9216 150652 884684   11    0   153    49 1552   408 12 
44 39  5
  2  1   9996   8796 150748 885064    0    0    91   615 1016   214  7 
42 39 12
  1  1   9996   8672 150784 885164    0    0    80   236  981   217  6 
37 52  5
  1  6   9996   8416 150856 885364    0    0    69   784  835   249  5 
34 12 49
  9  2   9996   8856 150916 885508    0    0    45   824  773   251  6 

Re: post-parser for language specific modification

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

Re: post-parser for language specific modification

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:

Re: Separating article and meta-content

In my point of view, meta tag must be separate to the article text. It is
very to disturbing to novice users.

The clean approach is the better approach for me. About how editing meta tag
part, a separate windows may be enough first, but the best may be to have a
check box list under article edit box for tags. For language links, it's a
little bit more difficult. :o/

Aoineko

From: "Erik Moeller"
> I believe we need to start thinking about ways to better separate content
> and metadata. Making them editable separately, and perhaps making either
> type of content filterable, gives us room for expansion in the meta realm
> without impacting editability for users who just want the plain text.
>
> Current meta-tags:
> * interlanguage links
> * __NOTOC__
> * __NOEDITSECTION__
> * category links (experimental)
>
> Possible future meta-tags:
> * <editnote> - shown on top of the edit box during editing, e.g. "Please
> describe new events in the present tense"
> * <sizelimit> - for auto-archiving or size warnings
> * __NOCACHE__
> * __NOTITLE__, __NOSUBTITLE__ for navigational pages, Main Page
> * [[Edition=Print]] and other name=value tags
> * .. anything else that would be useful, but clutter on the article page