Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)

[Michael Dale]

thanks for the constructive response :) ... comments inline

Tim Starling wrote:
I agree we should move things into a global object ie: $j and all our 
components / features should extend that object. (like jquery plugins). 
That is the direction we are already going.



I think it would be better if jQuery was called window.jQuery and
MediaWiki was called window.mw. Then we could share the jQuery
instance with JS code that's not aware of MediaWiki, and we wouldn't
need to worry about namespace conflicts between third-party jQuery
plugins and MediaWiki.
  
Right but there are benefits to connecting into the jQuery plugin system 
that would not be as clean to wrap into our window.mw object. For 
example $('#textbox').wikiEditor() is using jQuery selectors for the 
target, and maybe other jQuery plugin conventions like the jquery class 
alias inside the function(){})(jQuery);


Although if not designing your tool as a jQuery plugin then yea ;) ... 
but I think most of the tools should be designed as jQuery plug-ins.


Dependency loading is not really beyond the scope... we are already 
supporting that. If you check out the mv_jqueryBindings function in 
mv_embed.js ... here we have loader calls integrated into the jquery 
binding. This integrates loading the high level application interfaces 
into their interface call.



Your so-called dependency functions (e.g. doLoadDepMode) just seemed
to be a batch load feature, there was no actual dependency handling.
Every caller was required to list the dependencies for the classes it
was loading.
  


I was referring to defining the dependencies in the module call ... ie 
$j('target').addMediaWiz( config ) and having the addMediaWiz module map 
out the dependencies in the javascript. doLoadDepMode just lets you get 
around an IE bug that when inserting scripts via the dom you have no 
gurantee one script will execute in the order inserted. If you your 
conncatinaging your scripts doLoadDepMode would not be needed as order 
will be preserved in the concatenated file.


I like mapping out the dependencies in javascript at that module level 
since it makes it easier to do custom things like read the passed in 
configuration and decide which dependencies you need to fulfill. If not 
you have to define many dependency sets in php or have much more 
detailed model of your javscript inside php.


But I do understand that it will eventually result in lots of extra 
javascript module definitions that the given installation may not want. 
So perhaps we generate that module definition via php configuration ... 
or we define the set of javascript files to include that define the 
various module loaders we want with a given configuration.


This is sort the approach taken with the wikiEditor that has a few thin 
javascript files that make calls to add modules (like add-sidebar) to a 
core component  (wikiEditor).  That way the feature set can be 
controlled by the php configuration while retaining runtime flexibility 
for dependence mapping.


The idea is to move more and more of the structure of the application 
into that system. so right now mwLoad is a global function but should be 
re-factored into the jquery space and be called via $j.load();  |

|



That would work well until jQuery introduced its own script-loader
plugin with the same name and some extension needed to use it.


  


That is part of the idea of centrally hosting reusable client-side 
components so we control the jquery version and plugin set. So a new 
version won't "come along" until its been tested and integrated.


If the function does mediawiki specifc scriptloader load stuff then yea 
it should be called mwLoad or what not. If some other plugin or native 
jquery piece comes along we can just have our plugin override it and or 
store the native as a parent (if its of use) ... if that ever happens...



We could add that convention directly into the script-loader function if 
desired so that on a per class level we include dependencies. Like 
mwLoad('ui.dialog') would know to load ui.core etc.



Yes, that is what real dependency handling would do.
  


Thinking about this more ... I think its a bad idea to exclusively put 
the dependency mapping in php.  It will be difficult to avoid 
re-including the same things in client side loading chains. Say you have 
your suggest search system once the user starts typing we load 
jquery.suggest it knows that it needs jquery ui via dependency mapping 
stored in php. It sends both ui and suggest to the client. Now the user 
in the same page instance decides instead to edit a section. The 
editTool script-loader gets called its dependencies also include 
jquery.ui. How will the dependency-loader script-server know that the 
client already has the jquery.ui dependency from the suggest tool?


In the end you need these dependencies mapped out in the JS so that the 
client can intelligibly request the script set it needs.  In that same 
example if th

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brion Vibber]

On 9/25/09 6:11 PM, Robert Rohde wrote:
> On Fri, Sep 25, 2009 at 2:57 PM, Platonides  wrote:
>> Brian wrote:
>> XML is hard to edit. That's the reason wikitext was created, to "fix"
>> the issues with the, even easier, html.
>> Now, it is being proposed to add a XML processing on top of wikitext to
>> describe templates.
>
> 
>
> Unless expressly forbidden by the software implementation, I would
> assume that "helpful" Wikipedians would very quickly write template
> description templates to replace the XML and give it a "nice" wiki
> interface.  So, in practice, the question of whether XML is hard to
> edit will probably be moot and reduced solely to the issue that
> templates are hard to edit.

It's unlikely that many people will ever see or edit the XML as there'll 
be a perfectly good structured user interface.

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brion Vibber]

On 9/25/09 6:07 PM, Daniel Schwen wrote:
>> How a webmaster can make that text better? well.. you need to stop
>> using the HTML textarea widget. And emulate it with divs, css and
>> javascript. You need to colorize the code.  Nowdays *ALL* good code
>
> Or use a canvas..
> enter Bespin!
>
> https://bespin.mozilla.com/

Bespin is *very* cool, and we've definitely looked at it. (Even aside 
from the excellent syntax highlighting editor widget there are some 
*really* neat capabilities like the multi-user realtime editing, 
which if framed appropriately and combined with good chat tools could be 
insanely useful for Wikipedia.)

Right now it's quite an experimental project, though, and doesn't have a 
good way to support IE, so for our key efforts on syntax highlighting 
and content-folding we're looking mainly at using the browser-provided 
rich text edit widgets. This can unfortunately have performance problems 
so we may be limited in what we can do well, but hopefully that'll tide 
us over for a couple years. ;)

The wikEd editor gadget is an example of using this method to do syntax 
highlighting, though we'd want to scale it back to the key elements and 
avoid going overboard on the interface:

http://en.wikipedia.org/wiki/User:Cacycle/wikEd

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Robert Rohde]

On Fri, Sep 25, 2009 at 2:57 PM, Platonides  wrote:
> Brian wrote:
>> On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal wrote:
>>
>>>    * The topic is supposed to be on Template Editing which is, at least
>>>      in the way it's being proposed, a little less of a stale topic -
>>>      so where is all the energy on that front? We have an XML format to
>>>      design and complex problems to sort out. Help is really needed.
>>>      Let's all take a look at the link provided at the beginning of
>>>      this thread http://usability.wikimedia.org/wiki/Template_forms
>>>
>>> - Trevor
>>
>>
>> I do think that sufficient energy has been directed at this topic. People
>> have complained that xml is harder to edit that wikitext and that it is too
>> complicated, among other things.
>
> I think this is an important point.
>
> XML is hard to edit. That's the reason wikitext was created, to "fix"
> the issues with the, even easier, html.
> Now, it is being proposed to add a XML processing on top of wikitext to
> describe templates.



Unless expressly forbidden by the software implementation, I would
assume that "helpful" Wikipedians would very quickly write template
description templates to replace the XML and give it a "nice" wiki
interface.  So, in practice, the question of whether XML is hard to
edit will probably be moot and reduced solely to the issue that
templates are hard to edit.

-Robert Rohde

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Daniel Schwen]

> How a webmaster can make that text better? well.. you need to stop
> using the HTML textarea widget. And emulate it with divs, css and
> javascript. You need to colorize the code.  Nowdays *ALL* good code

Or use a canvas..
enter Bespin!

https://bespin.mozilla.com/

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Tei]

Hello.

Heres a screenshot of me editing the wikipedia:

http://zerror.com/unorganized/crap/nogoodenough.png

All the webmasters on this mail list will spot the problem with this
text  in 1 second: is unreadable. The space betwen lines, the lines
length, the complexity of the text... Is really hard to read.
A HTML textarea can server for writting emails, and simple text, but
on this image fail short. Textareas are not designed for this, or are
not good enough.

How a webmaster can make that text better? well.. you need to stop
using the HTML textarea widget. And emulate it with divs, css and
javascript. You need to colorize the code.  Nowdays *ALL* good code
editors colorize code. If our code editor don't colorize the wiki
sintax, or don't even try, our editor is bad. I could be wrong, but
maybe [[links]] and {{templates}} can be detected and colorized.   And
since you are emulating a editor, you can add a bit of usefull
beaviors:  make so some areas are read only, so the cursor skip then.
Oh.. and you can make the whole think AJAXified,.. so wen you click
[Edit section] this section become editable, and wen you "save", the
edit view send, and is replaced by the result. Why would you want to
people bounce here and there to post stuff in 2009?

He...  our computers support 24 M colors, and we are showing text with
2 colors? pfff





-- 
--
ℱin del ℳensaje.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 4:49 PM, Roan Kattouw wrote:

> 2009/9/26 Brian :
> > Roan, sorry that the idea is pretty hard to convey, I'll try again.
> > The basic idea is that you can create templates using templates
> > (just using current
> > tech). It's easy, you just pass parameters to a template that control
> > its output, and this
> > output is a new template. The parameters that you passed determine what
> the
> > new template looks like, and what it's output will be.
> >
> Right, so basically this is just templates calling other templates,
> right? This already happens to some degree already.
>
> > We can imagine a master template on Wikipedia that is used to generate
> all
> > infoboxes. It could work in arbitrary ways, but suppose it works this
> way:
> > The master infobox template creates a template for each wikiproject. The
> > template that it creates for each wikiproject further creates templates
> > representing every kind of infobox that this wikiproject uses. So you
> have a
> > master template that creates baby templates that create infobox
> templates.
> >
> > Using current tech this isn't exactly feasible, only advanced users will
> do
> > it since you have to directly interact with the templates and it would be
> > tough to code up. But if you make such a feature highly usable, by, for
> > example, tacking an easy to use interface on top of it, the usage of such
> > techniques will proliferate.
> >
> To use the master infobox example: such a template would have about a
> dozen usage modes, each with dozens of parameters. Such constructs are
> actually /easier/ to call by hand than with a form, because you'd
> either have to store all the relationships between the parameters and
> usage modes in the XML file and let the form handle all that (which is
> a degree of complexity I personally would not like to see in a
> template forms implementation) or just throw a couple hundred
> parameters in the user's face.
>
> Also, this being tough to code up would not change: again, we're not
> simplifying the *writing* of templates *themselves* in any way. The
> fact that these templates include template calls doesn't change that,
> because 1) you're gonna be using #if constructs all over the place
> anyway, 2) you'd need to use stuff like {{{2|{{{1|}} as arguments
> to template calls, which the GUI doesn't simplify and 3) if you're
> skilled enough to do 1 and 2 and familiar enough with the templates
> you're calling to be writing a master templates, you don't need an
> editor or form to build the template calls for you.
>
> > More general kinds of interface builders that build all imaginable kinds
> of
> > interfaces are conceivable.
> >
> > Is this not possible within the scope of the suggested system?
> >
> Yes, but it's also possible within the scope of the current system.
> You don't /need/ a template editor to be doing this kind of monkey
> business. In fact, I think a template editor would actually discourage
> these practices, because relatively unexperienced users must be able
> to build a reasonable template call using the template editor. For the
> latter to work out, templates need to be simpler rather than more
> complex.
>
> In short, I don't think introducing a template editor would encourage
> master templates and similar complexification of templates; in fact, I
> believe it will actually encourage simplification, because a
> nice-looking GUI for a big incomprehensible parameter soup is worth
> the soup.
>
> Roan Kattouw (Catrope)
>

* wizards, workflows, meta-interfaces, these are accidental implications of
a feature whose only purported design goal is to make editing templates on
articles easier. and i haven't been at all convinced that the new system
won't make it possible to create really elegant interfaces that are easy to
use. e.g., that make it really easy to create monstrosities of templates and
parser functions that no human can conceivably understand. :* historically,
if it can be done on the wiki it will be done
:* and it will be spread and copied, hundreds of thousands to millions of
times, within just a few years

* nobody intended to make template syntax turing complete - it was an
accident

* the obvious solution to templates is *not* to hack on an interface for
editing them. wikipedia is supposed to be the encyclopedia that anyone can
edit. it was a poor design decision to enable (or indeed, to create) a
template system on wikipedia that allowed people to create, in the first
place {{qif}}, and other things like it. the only reason even worse things
weren't created is that it was hard.
:* and the result of this accident was not just to put limits on
recursion and the things that could be done with templates, but to
further enable
those use cases (without much discussion or regard to long term strategy and
usability).

* so not only were templates bad, but this Incrementalism, otherwise known
as [[Feature creep]], which brion just described as his guiding "strat

Re: [Wikitech-l] Proposal for editing template calls within pages

[Platonides]

Roan Kattouw wrote:
> 2009/9/25 Platonides:
>> Those descriptions will have to be edited by the same user base that
>> edit all other pages. Even if they are power users, it's not easy to
>> write correct XML on the wiki textarea. We would need to create an
>> editor for the language being created so a template editor can be made.
>>
> Since the XML file describes the template, it need only be changed
> when the template is changed. Realistically, newbie editors don't edit
> templates; anyone skilled enough to edit templates can handle some
> simple XML.

But why make it harder?
You could also stat that anyone skilled enough to edit templates can
handle .
I wouldn't feel comfortable mannually editing XML. Or worse, reviewing
XML written by others that is invalid (How are you going to handle that?).


>> I advocate for a simpler syntax for form definition (but we shouldn't on
>> the way reinvent wikitext).
>>
> Exactly. XML is a decent choice here because it has a well-defined,
> pre-existing grammar with parsers already available, which means it's
> easy to parse and easy to learn (assuming you've got some shred of a
> technical background; see my earlier point about newbies not editing
> templates).
> 
> Roan Kattouw (Catrope)

However, it's not easy to type. It's convenient just for developers.
XML has the advantage of having many editors available, but if I need an
external editor, the system is broken.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JS2 design (was Re: Working towards branchingMediaWiki 1.16)

[Jared Williams]

 

> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org 
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of 
> Aryeh Gregor
> Sent: 25 September 2009 23:01
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards 
> branchingMediaWiki 1.16)
> 
> On Fri, Sep 25, 2009 at 3:46 PM, Steve Sanbeg 
wrote:
> > I'm not sure that's entirely accurate.  XSLT works on DOM trees,
so 
> > malformed XML shouldn't really apply.  Of course, the 
> standard command 
> > line processors create this tree with a standard parser, usually
an 
> > XML parser.  But in PHP, creating the DOM with a parser and 
> > transforming it with XSLT are handled separately.
> 
> Interesting.  In that case, theoretically, you could use an 
> HTML5 parser, which is guaranteed to *always* produce a DOM 
> even on random garbage input (much like wikitext!).  Now, 
> who's up for writing an
> HTML5 parser in PHP whose performance is acceptable?  I thought not.
> :P

libxml2, and therefore PHP has a tag soup HTML 4 parser. 

DOMDocument::loadHTML()

http://xmlsoft.org/html/libxml-HTMLparser.html

Jared


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Jared Williams]

 

> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org 
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of 
> Roan Kattouw
> Sent: 25 September 2009 23:39
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] Proposal for editing template calls 
> within pages
> 
> 2009/9/25 Platonides :
> > Those descriptions will have to be edited by the same user 
> base that 
> > edit all other pages. Even if they are power users, it's 
> not easy to 
> > write correct XML on the wiki textarea. We would need to create an

> > editor for the language being created so a template editor 
> can be made.
> >
> Since the XML file describes the template, it need only be 
> changed when the template is changed. Realistically, newbie 
> editors don't edit templates; anyone skilled enough to edit 
> templates can handle some simple XML.
> 
> > I advocate for a simpler syntax for form definition (but we 
> shouldn't 
> > on the way reinvent wikitext).
> >
> Exactly. XML is a decent choice here because it has a 
> well-defined, pre-existing grammar with parsers already 
> available, which means it's easy to parse and easy to learn 
> (assuming you've got some shred of a technical background; 
> see my earlier point about newbies not editing templates).
> 
> Roan Kattouw (Catrope)
> 

One thing I think might be missing from the example template
description is all the implicit parameters it depends on, like
language. 

Jared


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Roan Kattouw]

2009/9/26 Brian :
> Roan, sorry that the idea is pretty hard to convey, I'll try again.
> The basic idea is that you can create templates using templates
> (just using current
> tech). It's easy, you just pass parameters to a template that control
> its output, and this
> output is a new template. The parameters that you passed determine what the
> new template looks like, and what it's output will be.
>
Right, so basically this is just templates calling other templates,
right? This already happens to some degree already.

> We can imagine a master template on Wikipedia that is used to generate all
> infoboxes. It could work in arbitrary ways, but suppose it works this way:
> The master infobox template creates a template for each wikiproject. The
> template that it creates for each wikiproject further creates templates
> representing every kind of infobox that this wikiproject uses. So you have a
> master template that creates baby templates that create infobox templates.
>
> Using current tech this isn't exactly feasible, only advanced users will do
> it since you have to directly interact with the templates and it would be
> tough to code up. But if you make such a feature highly usable, by, for
> example, tacking an easy to use interface on top of it, the usage of such
> techniques will proliferate.
>
To use the master infobox example: such a template would have about a
dozen usage modes, each with dozens of parameters. Such constructs are
actually /easier/ to call by hand than with a form, because you'd
either have to store all the relationships between the parameters and
usage modes in the XML file and let the form handle all that (which is
a degree of complexity I personally would not like to see in a
template forms implementation) or just throw a couple hundred
parameters in the user's face.

Also, this being tough to code up would not change: again, we're not
simplifying the *writing* of templates *themselves* in any way. The
fact that these templates include template calls doesn't change that,
because 1) you're gonna be using #if constructs all over the place
anyway, 2) you'd need to use stuff like {{{2|{{{1|}} as arguments
to template calls, which the GUI doesn't simplify and 3) if you're
skilled enough to do 1 and 2 and familiar enough with the templates
you're calling to be writing a master templates, you don't need an
editor or form to build the template calls for you.

> More general kinds of interface builders that build all imaginable kinds of
> interfaces are conceivable.
>
> Is this not possible within the scope of the suggested system?
>
Yes, but it's also possible within the scope of the current system.
You don't /need/ a template editor to be doing this kind of monkey
business. In fact, I think a template editor would actually discourage
these practices, because relatively unexperienced users must be able
to build a reasonable template call using the template editor. For the
latter to work out, templates need to be simpler rather than more
complex.

In short, I don't think introducing a template editor would encourage
master templates and similar complexification of templates; in fact, I
believe it will actually encourage simplification, because a
nice-looking GUI for a big incomprehensible parameter soup is worth
the soup.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brion Vibber]

On 9/25/09 3:39 PM, Roan Kattouw wrote:
> 2009/9/25 Platonides:
>> Those descriptions will have to be edited by the same user base that
>> edit all other pages. Even if they are power users, it's not easy to
>> write correct XML on the wiki textarea. We would need to create an
>> editor for the language being created so a template editor can be made.
>>
> Since the XML file describes the template, it need only be changed
> when the template is changed. Realistically, newbie editors don't edit
> templates; anyone skilled enough to edit templates can handle some
> simple XML.
>
>> I advocate for a simpler syntax for form definition (but we shouldn't on
>> the way reinvent wikitext).
>>
> Exactly. XML is a decent choice here because it has a well-defined,
> pre-existing grammar with parsers already available, which means it's
> easy to parse and easy to learn (assuming you've got some shred of a
> technical background; see my earlier point about newbies not editing
> templates).

My preference is that we shouldn't actually expose the template 
definition markup at all during the normal course of events, even when 
changing a template.

The field metadata can be fairly straightforwardly displayed and edited 
through a nice web interface. XML as such is simply a conveniently 
well-defined structured data tree format which can be used both for 
storing the field metadata in the DB and exposing it to the template 
invocation editor interface (whether client-side JS or server-side PHP 
or a custom bot-based tool speaking to our API).


Of course if template creators *want* to dive into the raw field 
metadata definition as humans, we do love to expose such things to power 
power users for them to play with. :)

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Roan Kattouw]

2009/9/25 Platonides :
> Those descriptions will have to be edited by the same user base that
> edit all other pages. Even if they are power users, it's not easy to
> write correct XML on the wiki textarea. We would need to create an
> editor for the language being created so a template editor can be made.
>
Since the XML file describes the template, it need only be changed
when the template is changed. Realistically, newbie editors don't edit
templates; anyone skilled enough to edit templates can handle some
simple XML.

> I advocate for a simpler syntax for form definition (but we shouldn't on
> the way reinvent wikitext).
>
Exactly. XML is a decent choice here because it has a well-defined,
pre-existing grammar with parsers already available, which means it's
easy to parse and easy to learn (assuming you've got some shred of a
technical background; see my earlier point about newbies not editing
templates).

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brion Vibber]

On 9/25/09 2:23 PM, Brian wrote:
> You have conveniently ignored the rest of my points, which are not, as you
> have claimed, off topic. (and you love to jump into threads and claim they
> have become off topic, historically, with only the points that you are
> considering being on topic.)

I felt no reason to address them since they're stuck in the tangent 
discussion about redoing the entire markup system from top to bottom... 
again...

My experience based on 7 years of MediaWiki development is that this 
line of discussion has consistently lead to nothing useful being produced.

Rather than go in circles for the millionth time, I recommend sticking 
to definable, achievable goals which can build on each other -- such as 
the original topic of this thread.

> To wrap them up for you:
>
> * This will fundamentally change mediawiki and the consequences of this
> feature have not been considered

The direct consequence is that in the short term we'll actually be able 
to achieve the situation that normal people will be able to edit 
articles containing templates.

Having this infrastructure in place further means we're in a better 
position to someday make a major markup transition (say to a different 
markup system or not exposing markup at all in a pure-WYSIWYG 
environment)... something we're now very far from... but doesn't commit 
us to any markup changes in the near or medium term.

Morever this is all based on existing discussion, knowledge, and 
experience, not some sudden invention that's never been considered before.

The current work here is most directly inspired by existing systems in 
the German Wikipedia's Vorlagen-Meister gadget and the Semantic Forms 
extension... We're hardly creating an idea from whole cloth here; this 
is real stuff that's been done before in parts and needs to be cleaned 
up and modernized for Wikipedia's needs.

> * We cannot evaluate the repercussions of this feature with respect to our
> broader vision for mediawiki because we (by which I mean we, not you
> personally) do not have one.

Broadly, our strategy is as it always has been: to identify and 
implement real, measurable benefits to the reading and editing 
experiences of Wikipedia and other sites.

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 4:06 PM, Happy-melon  wrote:

>
> "Brian"  wrote in message
> news:9839a05c0909251423j7152ae51y34a6a9e586f4f...@mail.gmail.com...
> >
> > You have conveniently ignored the rest of my points, which are not, as
> you
> > have claimed, off topic. (and you love to jump into threads and claim
> they
> > have become off topic, historically, with only the points that you are
> > considering being on topic.)
>
> Considering that you're addressing the person who is ultimately responsible
> for drafting technical strategy for MediaWiki development, I'm not sure
> that
> asserting that his view of what comprises useful discussion is
> fundamentally
> flawed is a particularly constructive approach.
>
> --HM


I don't believe the technical strategy for MediaWiki has been drafted,
literally speaking.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 3:29 PM, Roan Kattouw wrote:

> 2009/9/25 Brian :
> > * This will fundamentally change mediawiki and the consequences of this
> > feature have not been considered
> > * It will support the creation of new interfaces from interfaces, simply
> by
> > creating templates that create new templates and using the interface to
> that
> > template to create the new interface. Is this correct?
> Wait, what? Can you explain this better or provide an example?
>
> Roan Kattouw (Catrope)
>
>
Roan, sorry that the idea is pretty hard to convey, I'll try again.
The basic idea is that you can create templates using templates
(just using current
tech). It's easy, you just pass parameters to a template that control
its output, and this
output is a new template. The parameters that you passed determine what the
new template looks like, and what it's output will be.

We can imagine a master template on Wikipedia that is used to generate all
infoboxes. It could work in arbitrary ways, but suppose it works this way:
The master infobox template creates a template for each wikiproject. The
template that it creates for each wikiproject further creates templates
representing every kind of infobox that this wikiproject uses. So you have a
master template that creates baby templates that create infobox templates.

Using current tech this isn't exactly feasible, only advanced users will do
it since you have to directly interact with the templates and it would be
tough to code up. But if you make such a feature highly usable, by, for
example, tacking an easy to use interface on top of it, the usage of such
techniques will proliferate.

More general kinds of interface builders that build all imaginable kinds of
interfaces are conceivable.

Is this not possible within the scope of the suggested system?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Happy-melon]

"Brian"  wrote in message 
news:9839a05c0909251423j7152ae51y34a6a9e586f4f...@mail.gmail.com...
>
> You have conveniently ignored the rest of my points, which are not, as you
> have claimed, off topic. (and you love to jump into threads and claim they
> have become off topic, historically, with only the points that you are
> considering being on topic.)

Considering that you're addressing the person who is ultimately responsible 
for drafting technical strategy for MediaWiki development, I'm not sure that 
asserting that his view of what comprises useful discussion is fundamentally 
flawed is a particularly constructive approach.

--HM 



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)

[Aryeh Gregor]

On Fri, Sep 25, 2009 at 3:46 PM, Steve Sanbeg  wrote:
> I'm not sure that's entirely accurate.  XSLT works on DOM trees, so
> malformed XML shouldn't really apply.  Of course, the standard command
> line processors create this tree with a standard parser, usually an XML
> parser.  But in PHP, creating the DOM with a parser and transforming it
> with XSLT are handled separately.

Interesting.  In that case, theoretically, you could use an HTML5
parser, which is guaranteed to *always* produce a DOM even on random
garbage input (much like wikitext!).  Now, who's up for writing an
HTML5 parser in PHP whose performance is acceptable?  I thought not.
:P

Anyway, my other points (e.g., may as well use PHP instead if you want
that much power) still hold.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Platonides]

Brian wrote:
> On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal wrote:
> 
>>* The topic is supposed to be on Template Editing which is, at least
>>  in the way it's being proposed, a little less of a stale topic -
>>  so where is all the energy on that front? We have an XML format to
>>  design and complex problems to sort out. Help is really needed.
>>  Let's all take a look at the link provided at the beginning of
>>  this thread http://usability.wikimedia.org/wiki/Template_forms
>>
>> - Trevor
> 
> 
> I do think that sufficient energy has been directed at this topic. People
> have complained that xml is harder to edit that wikitext and that it is too
> complicated, among other things.

I think this is an important point.

XML is hard to edit. That's the reason wikitext was created, to "fix"
the issues with the, even easier, html.
Now, it is being proposed to add a XML processing on top of wikitext to
describe templates.

Those descriptions will have to be edited by the same user base that
edit all other pages. Even if they are power users, it's not easy to
write correct XML on the wiki textarea. We would need to create an
editor for the language being created so a template editor can be made.

Look at
http://strategy.wikimedia.org/wiki/Call_for_participation/Task_force_application
It is a form definition, but the fields were defined like
* Name [SMALL TEXT FIELD]
* Email [SMALL TEXT FIELD]

It doesn't have a formal definition and is thus ambiguous, but it's an
example on how to make an user-friendly forms.

I advocate for a simpler syntax for form definition (but we shouldn't on
the way reinvent wikitext).

What about creating a  tag extension, with the elements
defined as a list?
It would implicitely be 
If there're several instances, they are equivalent as one instance whose
content is the concatenation of all of them (so parameters can be
documented inline).

For the example template, we could have:

*Author: Person who made the work.
Anonymous works not allowed.

*License: License under which the work can be used.
The license must be determined by the copyright holder, if in doubt, ask
on the [[WP:Village Pump|]].


We have two parameters: Author and License, with a short description
suitable as a caption, and a longer description available. Both fields
can allow wikitext (except list items for obvious reasons).

The syntax is simple to understand, and even with no special software,
it can be consulted by anyone.


Now we add parameters and form typing:

*Author:[TEXT] Person who made the work.
Anonymous works not allowed.

*License:{GFDL|CC-BY-SA}[Dropdown] License under which the work can be used.
The license must be determined by the copyright holder, if in doubt, ask
on the [[WP:Village Pump|]].
*Restrictions:[TEXTAREA] Additional restrictions imposed by the author.


As expected, it gets a bit uglier, but it's still straightforward.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Aryeh Gregor]

On Fri, Sep 25, 2009 at 1:53 PM, Gerard Meijssen
 wrote:
> This specific character mentioned in the article is used to write the
> Tanimuca-Retuarã language. This is specified in the article. itself.

Ethnologue says it has 300 speakers, if I'm reading it correctly:

http://www.ethnologue.com/show_language.asp?code=tnc

With a literacy rate of 5% or less, I guess that works out to 15
people in the world who can actually read or write it?  If I'm reading
the figures correctly, Tanimuca-Retuarã is drastically below the
threshold where there can be any serious question of creating
educational resources in the language, so I really don't think
Wikimedia needs to concern itself with it.

In any event, we are talking about an article on the *English*
Wikipedia, and what the *English* Wikipedia should do when this
situation arises.  I made no comment on anything relating to anyone
trying to write Tanimuca-Retuarã, which nobody is on the English
Wikipedia.  It's a non sequitur.

> Languages that need characters that are missing in fonts that are in general
> use are not isolated affairs. In the end there is only one solution; we
> should be part of a solution that allows us to show all characters.

Those who want to help building fonts can feel free to do so.  It will
not change the fact that as Unicode expands, support for new additions
will be gradual, and wikis need to figure out something to do when a
character is not well supported by their viewers.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Roan Kattouw]

2009/9/25 Brian :
> * This will fundamentally change mediawiki and the consequences of this
> feature have not been considered
> * It will support the creation of new interfaces from interfaces, simply by
> creating templates that create new templates and using the interface to that
> template to create the new interface. Is this correct?
Wait, what? Can you explain this better or provide an example?

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 3:13 PM, Brion Vibber  wrote:

> On 9/25/09 11:39 AM, Brian wrote:
> > I do think that sufficient energy has been directed at this topic. People
> > have complained that xml is harder to edit that wikitext and that it is
> too
> > complicated, among other things.
>
> You seem to be talking about something utterly unrelated to this thread...
>
> The only XML under discussion here is an internal back-end
> representation of template metadata to drive a sane template invocation
> user-interface:
>
> * field names and descriptions (localizable)
> * field types/validation info
> * field grouping and optional/required info
> * other documentation & display info
>
> This would not be exposed to editors, viewers or readers; nor is it in
> any way related to whether, how, or when we might some day alter or
> replace wiki markup.
>
> -- brion


You have conveniently ignored the rest of my points, which are not, as you
have claimed, off topic. (and you love to jump into threads and claim they
have become off topic, historically, with only the points that you are
considering being on topic.)

To wrap them up for you:

* This will fundamentally change mediawiki and the consequences of this
feature have not been considered
* It will support the creation of new interfaces from interfaces, simply by
creating templates that create new templates and using the interface to that
template to create the new interface. Is this correct?
* We cannot evaluate the repercussions of this feature with respect to our
broader vision for mediawiki because we (by which I mean we, not you
personally) do not have one.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brion Vibber]

On 9/25/09 11:39 AM, Brian wrote:
> I do think that sufficient energy has been directed at this topic. People
> have complained that xml is harder to edit that wikitext and that it is too
> complicated, among other things.

You seem to be talking about something utterly unrelated to this thread...

The only XML under discussion here is an internal back-end 
representation of template metadata to drive a sane template invocation 
user-interface:

* field names and descriptions (localizable)
* field types/validation info
* field grouping and optional/required info
* other documentation & display info

This would not be exposed to editors, viewers or readers; nor is it in 
any way related to whether, how, or when we might some day alter or 
replace wiki markup.

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikitext vs. WYSIWYG

[Platonides]

Aryeh Gregor wrote:
> On Thu, Sep 24, 2009 at 8:34 PM, Jacopo Corbetta
>  wrote:
>> (HTML-style headings do not show up in the TOC, an odd
>> wikitext feature which we surely don't want newbies to use).
> 
> HTML-style headings do show up in the TOC, and have for a few years as
> far as I know.

HTML heading have changed status several times.
Currently, they are shown in TOC, but don't have edit link.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 2:42 PM, Roan Kattouw wrote:

> 2009/9/25 Brian :
> > However powerful it is, I'm not sure we can really rule out future
> > incompatibility as you suggest by simply stating that we can easily
> > forwardport. This feature is intended to hack a fix on top of the
> usability
> > issues inherent in templates. Every time we have a discussion about the
> > pitfalls of wikitext the center of this discussion is templates. Even
> > without parser functions they are turing complete - with them it is a
> > complete usability disaster. So it seems that when we finally get around
> to
> > developing a consensus about the changes we want in wikitext, there will
> be
> > widespread agreement that we need to change templates. But so far,
> without
> > any clear strategy on that front, we have no idea what those changes will
> > be.
> >
> It's important to separate template *calls* from template
> *implementation*: only the latter involves ParserFunctions and all
> that other ugliness. Even if and when we do completely redo the way
> templates are *written* on the inside, the way they're *called* from
> the outside would probably not change significantly, nor would the
> concepts of parameters and types. This means redoing template syntax
> does not require any changes to the XML format.
>
> Roan Kattouw (Catrope)
>

It's certainly possible, particularly with something as generic as xml, to
create an extension to mediawiki that supports a variety of backends.

As I've suggested, however, without any clear vision of where we want
wikitext, and more generally, MediaWiki to go, then it is impossible to
evaluate the efficacy of this feature, especially considering that the
consequences of it haven't even been evaluated. Given the power of the
backend that this feature will be kludged on top of it will fundamentally
change MediaWiki is used. And yet, I just checked Strategy, there is no
vision for where MediaWiki should go moving into the future, let alone
wikitext. As far as I can tell this feature was cooked up in order to
improve usability, and yet when you improve usability by definition you make
the software easier to use and provide new affordances to your users. We
have no idea whether these affordances are in line with our general vision
for how users should interact with MediaWiki because we simply do not have
one. I have never seen a discussion about whether the ability to create new
interfaces via an interface is in line with either our lesser mission to
build an encyclopedia or our greater one to bring knowledge to every human
being. Lastly I would just point out that everything that can be done with
this new feature will be done, and I invoke the spirit of #qif to make my
point.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Tisza Gergő]

Nikola Smolenski  eunet.rs> writes:

> What I am going to say is going to be the worst heresy, but could this 
> problem be solved by gradually migrating to a new wiki markup, for 
> example **bold** and //italic//? This markup is more logical and easier 
> to remember, more used outside of MediaWiki (unofficial email markup is 
> similar) and more easily visible than apostrophe markup, and I never 
> understood how the apostrophes came to be in the first place. The most 
> important for this discussion - it also has much less potential to 
> confuse the parser.

You avoid a lot of pain if the opening and closing markup is different. 
That is IMHO the other big problem besides reusing the same characters in ''/'''
and {{/{{{.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Roan Kattouw]

2009/9/25 Brian :
> However powerful it is, I'm not sure we can really rule out future
> incompatibility as you suggest by simply stating that we can easily
> forwardport. This feature is intended to hack a fix on top of the usability
> issues inherent in templates. Every time we have a discussion about the
> pitfalls of wikitext the center of this discussion is templates. Even
> without parser functions they are turing complete - with them it is a
> complete usability disaster. So it seems that when we finally get around to
> developing a consensus about the changes we want in wikitext, there will be
> widespread agreement that we need to change templates. But so far, without
> any clear strategy on that front, we have no idea what those changes will
> be.
>
It's important to separate template *calls* from template
*implementation*: only the latter involves ParserFunctions and all
that other ugliness. Even if and when we do completely redo the way
templates are *written* on the inside, the way they're *called* from
the outside would probably not change significantly, nor would the
concepts of parameters and types. This means redoing template syntax
does not require any changes to the XML format.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 2:20 PM, Roan Kattouw wrote:

> 2009/9/25 Brian :
> > I am not here saying that it is a bad feature, not a bit. In fact I have
> > previously advocated on this list for the ability for users to specify
> > form-like interfaces. What I am saying is that I think it's premature.
> There
> > is a tradeoff that needs to be balanced here. It's easy to add new
> features
> > and hard to fix the old one. As we add new features however we diverse
> > farther and farther from the possibility of fixing wikitext. This is
> > especially when efforts to add new features are done entirely out of the
> > context of a clear strategy for eventually fixing wikitext.
> >
> > So before a feature such as this is implemented, or any new substantial
> > language is added to MediaWiki (such as ParserFunctions, or this
> interface
> > specification language), I would like to see work done on the Strategy
> wiki.
> > I don't think new work such as this should be done outside of the context
> of
> > a very clear vision of how we will eventually fix the whole problem. And
> I'm
> > entirely willing to help.
> You seem to be missing my point (or at least are not refuting it): if
> implemented properly, with the minimal assumptions I mentioned,
> subsequent reworking of wikitext *wouldn't* *matter*, because the
> template call editor could easily be ported to the 'new language' or
> whatever we end up with. It wouldn't put us any further away from
> fixing wikitext; the trade-off you mentioned does not exist IMO.
>
> Roan Kattouw (Catrope)
>

I think calling it a 'template call editor' does not do the proposed new
feature justice. It would fundamentally change MediaWiki. Once this language
is created it will, if I understand it correctly (please correct me if I
don't), immediately support the creation of interfaces that automatically
create new interfaces, and so on and so forth. It is a fundamental departure
from the way we currently do things on the wiki.

However powerful it is, I'm not sure we can really rule out future
incompatibility as you suggest by simply stating that we can easily
forwardport. This feature is intended to hack a fix on top of the usability
issues inherent in templates. Every time we have a discussion about the
pitfalls of wikitext the center of this discussion is templates. Even
without parser functions they are turing complete - with them it is a
complete usability disaster. So it seems that when we finally get around to
developing a consensus about the changes we want in wikitext, there will be
widespread agreement that we need to change templates. But so far, without
any clear strategy on that front, we have no idea what those changes will
be.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Roan Kattouw]

2009/9/25 Brian :
> I am not here saying that it is a bad feature, not a bit. In fact I have
> previously advocated on this list for the ability for users to specify
> form-like interfaces. What I am saying is that I think it's premature. There
> is a tradeoff that needs to be balanced here. It's easy to add new features
> and hard to fix the old one. As we add new features however we diverse
> farther and farther from the possibility of fixing wikitext. This is
> especially when efforts to add new features are done entirely out of the
> context of a clear strategy for eventually fixing wikitext.
>
> So before a feature such as this is implemented, or any new substantial
> language is added to MediaWiki (such as ParserFunctions, or this interface
> specification language), I would like to see work done on the Strategy wiki.
> I don't think new work such as this should be done outside of the context of
> a very clear vision of how we will eventually fix the whole problem. And I'm
> entirely willing to help.
You seem to be missing my point (or at least are not refuting it): if
implemented properly, with the minimal assumptions I mentioned,
subsequent reworking of wikitext *wouldn't* *matter*, because the
template call editor could easily be ported to the 'new language' or
whatever we end up with. It wouldn't put us any further away from
fixing wikitext; the trade-off you mentioned does not exist IMO.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Trevor Parscal]

On 9/25/09 1:18 PM, Robert Rohde wrote:
> Are the XML specifications intended as?
>
> A) A required addition to current and future templates
>
> OR
>
> B) An optional addition to aid / facilitate the functioning of some
> advanced tools
>
> The latter case seems far more achievable than the former case.
>
> -Robert Rohde
>
> On Fri, Sep 25, 2009 at 12:49 PM, Roan Kattouw  wrote:
>
>> 2009/9/25 Brian:
>>  
>>> Also, I am quite serious about my point that an entirely
>>> new language interface specification will be added to MediaWiki and that it
>>> will be widely adopted and propagate throughout the wikisphere, much like
>>> parser functions, and in the end will make the job of fixing MediaWiki much,
>>> much harder.
>>>
>> Whatever wikitext ends up becoming, it will probably still have
>> templates in some form. If the XML language is designed properly, it
>> won't make any assumptions about the current state of wikitext and
>> templates, other than that:
>>
>> * there are such things as templates
>> * they accept parameters
>> * parameters can, but need not, have names, types, descriptions, etc.;
>> types may or may not be enforced
>>
>> This very limited set of assumptions will hold in any language that
>> implements templates in a remotely sane way.
>>
>>  
>>>  From what I have
>>> heard, there was a meeting about how to solve this problem among core devs
>>> and a few others at wikimedia headquarters, they decided what the solution
>>> would be
>>>
>> That's news to me; I'd very much like to hear from these people what
>> their proposed solution is.
>>
>>  
>>> , and now you guys are moving forward on implementing it, totally
>>> ignoring the strategy wiki.
>>>
>> You make it sound like we're just going ahead and doing this, totally
>> ignoring everyone else's opinions. Instead, we're proposing and
>> discussing it on this list to get input from other people. If you
>> think there's a more appropriate place to discuss this, just point us
>> there; don't go around blasting us because we failed to read your
>> mind.
>>
>> Roan Kattouw (Catrope)
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>  
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
The latter case for sure. Without the additional information, editing a 
template call will just be a list of field names and text inputs.

- Trevor

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 2:14 PM, Alex  wrote:

> Brian wrote:
> > On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal  >wrote:
> >
> >>* The topic is supposed to be on Template Editing which is, at least
> >>  in the way it's being proposed, a little less of a stale topic -
> >>  so where is all the energy on that front? We have an XML format to
> >>  design and complex problems to sort out. Help is really needed.
> >>  Let's all take a look at the link provided at the beginning of
> >>  this thread http://usability.wikimedia.org/wiki/Template_forms
> >>
> >> - Trevor
> >
> >
> > I do think that sufficient energy has been directed at this topic. People
> > have complained that xml is harder to edit that wikitext and that it is
> too
> > complicated, among other things. Additionally, several people have
> pointed
> > out that solving this little part of the problem doesn't make sense in
> the
> > context of the larger problem at hand here. You are trying to separate
> the
> > issue of template editing from the larger issue of wikitext, and that
> > doesn't make sense. Also, I am quite serious about my point that an
> entirely
> > new language interface specification will be added to MediaWiki and that
> it
> > will be widely adopted and propagate throughout the wikisphere, much like
> > parser functions, and in the end will make the job of fixing MediaWiki
> much,
> > much harder. As it is very important developers already thing the problem
> is
> > so hard as to be impossible. I disagree with that, but at the same time I
> > don't think it's a good idea to make it even harder.
> >
> > So I don't think help is needed in designing a new xml interface
> > specification for mediawiki right now. I'm also a bit confused, because I
> > thought we had this new strategic planning wiki, but it looks like the
> > strategy aspect of this proposal is being largely ignored. From what I
> have
> > heard, there was a meeting about how to solve this problem among core
> devs
> > and a few others at wikimedia headquarters, they decided what the
> solution
> > would be, and now you guys are moving forward on implementing it, totally
> > ignoring the strategy wiki.
>
> AFAIK, the strategy wiki is designed to help formulate a 5-year
> strategic plan. According to the timeline, actual execution may not
> begin for at least another 4 months.[1] The usability project has its
> own timeline and deadlines and is more concerned more with short and
> medium term projects. I don't know if there is any plan to continue
> funding the usability initiative after the Stanton Foundation grant runs
> out.
>
> [1]
>
> --
> Alex (wikipedia:en:User:Mr.Z-man)
>
>
>
The vision for the strategy wiki is much, much broader than that. Here is a
recent e-mail from Sue on the subject:



On Tue, Sep 22, 2009 at 7:35 PM, Sue Gardner  wrote:

> 2009/9/22 Eugene Eric Kim :
> > On Mon, Sep 14, 2009 at 3:49 PM, Pavlo Shevelo 
> wrote:
> >> "Who will decide what the strategy will be, and what will be the
> >> decision-making process?"
> >>
> >> this page explains nothing about (or explains in no detail if somebody
> >> prefers) how main stakeholder - Foundation will make decision about
> >> said strategy. The huge, extremely intensive (and effective, if we
> >> will do our best) Earth-wide pipeline for proposal preparation - it's
> >> good. But what will be in the very end? How Foundation will decide
> >> what idea is good enough to stand behind it (and to put money in it)?
> >
> > Sorry for taking so long to respond, Pavlo. I'm not sure I'm the right
> > person to respond to this. I'll do my best, you can tell me if you
> > think it's clear, and hopefully other folks from the Foundation will
> > jump in.
>
> I just saw this thread; I'm happy to jump in.
>
> What Eugene says is all accurate -- let me expand a little.
>
> Essentially, the purpose of the project is to develop a strategy for
> the Wikimedia movement, not just for the Wikimedia Foundation.  What
> that means is that no single entity will be able to approve and drive
> forward the whole thing: individual players will drive forward the
> pieces that compel and engage and inspire them.
>
> So for example:
>
> * If it looks like it makes sense to stage a lot of events aimed at
> broadening participation in developed countries, the chapters would
> logically take the lead on that.
>
> * If it looks like it would make sense to conduct a massive awareness
> campaign in India, that would probably be moved forward in partnership
> between the Wikimedia Foundation and what might be -by then- an
> approved, new Indian chapter.
>
> * If it looks like a very strong focus on mobile makes sense, I expect
> that would be something driven forward by the tech staff at Wikimedia,
> in partnership with individual volunteer devs, and possibly supported
> by relationships with for-profit firms such as Orange.
>
> * If there is

Re: [Wikitech-l] Proposal for editing template calls within pages

[Robert Rohde]

Are the XML specifications intended as?

A) A required addition to current and future templates

OR

B) An optional addition to aid / facilitate the functioning of some
advanced tools

The latter case seems far more achievable than the former case.

-Robert Rohde

On Fri, Sep 25, 2009 at 12:49 PM, Roan Kattouw  wrote:
> 2009/9/25 Brian :
>> Also, I am quite serious about my point that an entirely
>> new language interface specification will be added to MediaWiki and that it
>> will be widely adopted and propagate throughout the wikisphere, much like
>> parser functions, and in the end will make the job of fixing MediaWiki much,
>> much harder.
> Whatever wikitext ends up becoming, it will probably still have
> templates in some form. If the XML language is designed properly, it
> won't make any assumptions about the current state of wikitext and
> templates, other than that:
>
> * there are such things as templates
> * they accept parameters
> * parameters can, but need not, have names, types, descriptions, etc.;
> types may or may not be enforced
>
> This very limited set of assumptions will hold in any language that
> implements templates in a remotely sane way.
>
>> From what I have
>> heard, there was a meeting about how to solve this problem among core devs
>> and a few others at wikimedia headquarters, they decided what the solution
>> would be
> That's news to me; I'd very much like to hear from these people what
> their proposed solution is.
>
>> , and now you guys are moving forward on implementing it, totally
>> ignoring the strategy wiki.
> You make it sound like we're just going ahead and doing this, totally
> ignoring everyone else's opinions. Instead, we're proposing and
> discussing it on this list to get input from other people. If you
> think there's a more appropriate place to discuss this, just point us
> there; don't go around blasting us because we failed to read your
> mind.
>
> Roan Kattouw (Catrope)
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Alex]

Brian wrote:
> On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal 
> wrote:
> 
>>* The topic is supposed to be on Template Editing which is, at least
>>  in the way it's being proposed, a little less of a stale topic -
>>  so where is all the energy on that front? We have an XML format to
>>  design and complex problems to sort out. Help is really needed.
>>  Let's all take a look at the link provided at the beginning of
>>  this thread http://usability.wikimedia.org/wiki/Template_forms
>>
>> - Trevor
> 
> 
> I do think that sufficient energy has been directed at this topic. People
> have complained that xml is harder to edit that wikitext and that it is too
> complicated, among other things. Additionally, several people have pointed
> out that solving this little part of the problem doesn't make sense in the
> context of the larger problem at hand here. You are trying to separate the
> issue of template editing from the larger issue of wikitext, and that
> doesn't make sense. Also, I am quite serious about my point that an entirely
> new language interface specification will be added to MediaWiki and that it
> will be widely adopted and propagate throughout the wikisphere, much like
> parser functions, and in the end will make the job of fixing MediaWiki much,
> much harder. As it is very important developers already thing the problem is
> so hard as to be impossible. I disagree with that, but at the same time I
> don't think it's a good idea to make it even harder.
> 
> So I don't think help is needed in designing a new xml interface
> specification for mediawiki right now. I'm also a bit confused, because I
> thought we had this new strategic planning wiki, but it looks like the
> strategy aspect of this proposal is being largely ignored. From what I have
> heard, there was a meeting about how to solve this problem among core devs
> and a few others at wikimedia headquarters, they decided what the solution
> would be, and now you guys are moving forward on implementing it, totally
> ignoring the strategy wiki.

AFAIK, the strategy wiki is designed to help formulate a 5-year
strategic plan. According to the timeline, actual execution may not
begin for at least another 4 months.[1] The usability project has its
own timeline and deadlines and is more concerned more with short and
medium term projects. I don't know if there is any plan to continue
funding the usability initiative after the Stanton Foundation grant runs
out.

[1]

-- 
Alex (wikipedia:en:User:Mr.Z-man)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 2:03 PM, Brian  wrote:

>
>
> On Fri, Sep 25, 2009 at 1:49 PM, Roan Kattouw wrote:
>
>> 2009/9/25 Brian :
>> > Also, I am quite serious about my point that an entirely
>> > new language interface specification will be added to MediaWiki and that
>> it
>> > will be widely adopted and propagate throughout the wikisphere, much
>> like
>> > parser functions, and in the end will make the job of fixing MediaWiki
>> much,
>> > much harder.
>> Whatever wikitext ends up becoming, it will probably still have
>> templates in some form. If the XML language is designed properly, it
>> won't make any assumptions about the current state of wikitext and
>> templates, other than that:
>>
>> * there are such things as templates
>> * they accept parameters
>> * parameters can, but need not, have names, types, descriptions, etc.;
>> types may or may not be enforced
>>
>> This very limited set of assumptions will hold in any language that
>> implements templates in a remotely sane way.
>>
>> > From what I have
>> > heard, there was a meeting about how to solve this problem among core
>> devs
>> > and a few others at wikimedia headquarters, they decided what the
>> solution
>> > would be
>> That's news to me; I'd very much like to hear from these people what
>> their proposed solution is.
>>
>> > , and now you guys are moving forward on implementing it, totally
>> > ignoring the strategy wiki.
>> You make it sound like we're just going ahead and doing this, totally
>> ignoring everyone else's opinions. Instead, we're proposing and
>> discussing it on this list to get input from other people. If you
>> think there's a more appropriate place to discuss this, just point us
>> there; don't go around blasting us because we failed to read your
>> mind.
>>
>> Roan Kattouw (Catrope)
>
>
>
> It appears that there is a desire for this project to fit within the scope of 
> the Usability Initiative, which to me says that there is a strong desire to 
> implement it starting soon. Trevor's e-mail indicates as much - let's stop 
> talking strategy and start designing so we can implement.
>
> I believe there was a meeting at headquarters with Brion, Trevor, Yaron,
> and maybe others. I don't know, I wasn't there. All I know is that at this
> meeting they decided that they would implement this feature. The XML aspect
> is honestly immaterial to me - it's just an implementational detail, the
> decision to do this having been decided entirely off wiki.
>
> I am not here saying that it is a bad feature, not a bit. In fact I have
> previously advocated on this list for the ability for users to specify
> form-like interfaces. What I am saying is that I think it's premature. There
> is a tradeoff that needs to be balanced here. It's easy to add new features
> and hard to fix the old one. As we add new features however we diverse
> farther and farther from the possibility of fixing wikitext. This is
> especially when efforts to add new features are done entirely out of the
> context of a clear strategy for eventually fixing wikitext.
>
> So before a feature such as this is implemented, or any new substantial
> language is added to MediaWiki (such as ParserFunctions, or this interface
> specification language), I would like to see work done on the Strategy wiki.
> I don't think new work such as this should be done outside of the context of
> a very clear vision of how we will eventually fix the whole problem. And I'm
> entirely willing to help.
>
>
Sorry for my typos: one -> ones, diverse -> diverge.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 1:49 PM, Roan Kattouw wrote:

> 2009/9/25 Brian :
> > Also, I am quite serious about my point that an entirely
> > new language interface specification will be added to MediaWiki and that
> it
> > will be widely adopted and propagate throughout the wikisphere, much like
> > parser functions, and in the end will make the job of fixing MediaWiki
> much,
> > much harder.
> Whatever wikitext ends up becoming, it will probably still have
> templates in some form. If the XML language is designed properly, it
> won't make any assumptions about the current state of wikitext and
> templates, other than that:
>
> * there are such things as templates
> * they accept parameters
> * parameters can, but need not, have names, types, descriptions, etc.;
> types may or may not be enforced
>
> This very limited set of assumptions will hold in any language that
> implements templates in a remotely sane way.
>
> > From what I have
> > heard, there was a meeting about how to solve this problem among core
> devs
> > and a few others at wikimedia headquarters, they decided what the
> solution
> > would be
> That's news to me; I'd very much like to hear from these people what
> their proposed solution is.
>
> > , and now you guys are moving forward on implementing it, totally
> > ignoring the strategy wiki.
> You make it sound like we're just going ahead and doing this, totally
> ignoring everyone else's opinions. Instead, we're proposing and
> discussing it on this list to get input from other people. If you
> think there's a more appropriate place to discuss this, just point us
> there; don't go around blasting us because we failed to read your
> mind.
>
> Roan Kattouw (Catrope)


It appears that there is a desire for this project to fit within the
scope of the Usability Initiative, which to me says that there is a
strong desire to implement it starting soon. Trevor's e-mail indicates
as much - let's stop talking strategy and start designing so we can
implement.

I believe there was a meeting at headquarters with Brion, Trevor, Yaron, and
maybe others. I don't know, I wasn't there. All I know is that at this
meeting they decided that they would implement this feature. The XML aspect
is honestly immaterial to me - it's just an implementational detail, the
decision to do this having been decided entirely off wiki.

I am not here saying that it is a bad feature, not a bit. In fact I have
previously advocated on this list for the ability for users to specify
form-like interfaces. What I am saying is that I think it's premature. There
is a tradeoff that needs to be balanced here. It's easy to add new features
and hard to fix the old one. As we add new features however we diverse
farther and farther from the possibility of fixing wikitext. This is
especially when efforts to add new features are done entirely out of the
context of a clear strategy for eventually fixing wikitext.

So before a feature such as this is implemented, or any new substantial
language is added to MediaWiki (such as ParserFunctions, or this interface
specification language), I would like to see work done on the Strategy wiki.
I don't think new work such as this should be done outside of the context of
a very clear vision of how we will eventually fix the whole problem. And I'm
entirely willing to help.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Roan Kattouw]

2009/9/25 Brian :
> Also, I am quite serious about my point that an entirely
> new language interface specification will be added to MediaWiki and that it
> will be widely adopted and propagate throughout the wikisphere, much like
> parser functions, and in the end will make the job of fixing MediaWiki much,
> much harder.
Whatever wikitext ends up becoming, it will probably still have
templates in some form. If the XML language is designed properly, it
won't make any assumptions about the current state of wikitext and
templates, other than that:

* there are such things as templates
* they accept parameters
* parameters can, but need not, have names, types, descriptions, etc.;
types may or may not be enforced

This very limited set of assumptions will hold in any language that
implements templates in a remotely sane way.

> From what I have
> heard, there was a meeting about how to solve this problem among core devs
> and a few others at wikimedia headquarters, they decided what the solution
> would be
That's news to me; I'd very much like to hear from these people what
their proposed solution is.

> , and now you guys are moving forward on implementing it, totally
> ignoring the strategy wiki.
You make it sound like we're just going ahead and doing this, totally
ignoring everyone else's opinions. Instead, we're proposing and
discussing it on this list to get input from other people. If you
think there's a more appropriate place to discuss this, just point us
there; don't go around blasting us because we failed to read your
mind.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)

[Steve Sanbeg]

On Fri, 25 Sep 2009 09:48:04 -0400, Aryeh Gregor wrote:

> On Fri, Sep 25, 2009 at 1:19 AM, Tim Starling 
> wrote:
>> On this point, I think we need:
>> * Easier management of non-PHP skins (i.e. CSS and images only) *
>> Automated CSS generation (per original post) * Easier ways to modify the
>> document structure, with less PHP involved. XSLT?
>> * An interface in PHP that we can live with, so we don't feel obliged to
>> keep breaking it.
> 
> XSLT is a non-starter unless we want fatal errors (or at least the skin
> completely breaking) on pages where we emit malformed XML.  And there
> always have been some of those, and probably always will be. Probably even
> more significantly, XSLT is a programming language and a rather obscure
> one.  If we're going to make MediaWiki skins so hard to make, we may as
> well stick with just requiring that they be in PHP.
> 

I'm not sure that's entirely accurate.  XSLT works on DOM trees, so
malformed XML shouldn't really apply.  Of course, the standard command
line processors create this tree with a standard parser, usually an XML
parser.  But in PHP, creating the DOM with a parser and transforming it
with XSLT are handled separately.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Links to Wikipedia with .htm at the end

[Robert Rohde]

On Thu, Sep 24, 2009 at 5:18 AM, Nikola Smolenski  wrote:
> I have noticed that a number (hundreds) of links to Wikipedia exist
> that are of the form http://xx.wikipedia.org/wiki/whatever.htm See this
> Google search for an overview:
> http://www.google.com/search?hl=en&q=%22wikipedia.org%2Fwiki+*+htm%22
>
> Is this way of linking a consequence of some bad editing tools appending
> .htm automatically, or were these links once actually valid? If they
> were, should they somehow be made to continue working? I saw at least
> one printed scientific work using such a link:
> http://scindeks.nb.rs/article.aspx?artid=0353-79190804835R&lang=en cites
> http://Wikipedia.org/wiki/contraception.htm
>
> On a related note, an interesting example I noticed in
> http://www.library.ait.ac.th/ThesisSearch/summary/Debajit%20Dutta.pdf
> that links to www.wiki.wikipedia.org/wiki/urban_heat_island.htm - did
> this www.wiki.wikipedia.org server really exist?

Issues like this do suggest that it would be nice if the noarticletext
message had a way of making "did you mean" style guesses for common
problem like this.

-Robert Rohde

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Brian]

On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal wrote:

>
>* The topic is supposed to be on Template Editing which is, at least
>  in the way it's being proposed, a little less of a stale topic -
>  so where is all the energy on that front? We have an XML format to
>  design and complex problems to sort out. Help is really needed.
>  Let's all take a look at the link provided at the beginning of
>  this thread http://usability.wikimedia.org/wiki/Template_forms
>
> - Trevor


I do think that sufficient energy has been directed at this topic. People
have complained that xml is harder to edit that wikitext and that it is too
complicated, among other things. Additionally, several people have pointed
out that solving this little part of the problem doesn't make sense in the
context of the larger problem at hand here. You are trying to separate the
issue of template editing from the larger issue of wikitext, and that
doesn't make sense. Also, I am quite serious about my point that an entirely
new language interface specification will be added to MediaWiki and that it
will be widely adopted and propagate throughout the wikisphere, much like
parser functions, and in the end will make the job of fixing MediaWiki much,
much harder. As it is very important developers already thing the problem is
so hard as to be impossible. I disagree with that, but at the same time I
don't think it's a good idea to make it even harder.

So I don't think help is needed in designing a new xml interface
specification for mediawiki right now. I'm also a bit confused, because I
thought we had this new strategic planning wiki, but it looks like the
strategy aspect of this proposal is being largely ignored. From what I have
heard, there was a meeting about how to solve this problem among core devs
and a few others at wikimedia headquarters, they decided what the solution
would be, and now you guys are moving forward on implementing it, totally
ignoring the strategy wiki.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Trevor Parscal]

This thread has gotten WAY off topic - so I wanted to try and help 
clarify a few things and then get it back on-topic if at all possible.

* As Roan mentioned, we are planning on implementing a *wiki-text
  *editing interface with collapsible blocks for template calls and
  tables. We may also get a bonus of basic syntax highlighting, but
  that's not a driving feature.
* WYSIWYG is a hope, dream, intention, and long-term-plan of the
  Wikimedia Foundation - but it's not going to be a reality until we
  can make progress in at least 3 areas (explained below) and
  perhaps others as well.
* It's important to understand that wiki-text it'self is not the
  enemy of WYSIWYG, these (and perhaps others as well) are...
  o *Data corruption: *All current solutions convert wiki-text
to some kind of HTML, edit it as if it were HTML, and then
convert it back, causing disconnection between the original
content and edited content. This in-turn  causes diffs to
show changes made by the lossy process for conversion such
as white-space, tables being in short or long notation, and
HTML comments being stripped. More importantly of course, it
changes the wiki-text of the page in ways the user did not
intend to and wipes out important formatting and comments
that people using text editing interfaces (by choice or
because their browser is unsupported) need, want and use.*
*
  o *Template abuse: *Template calls do not always result in
whole objects. When expanding a template, the result is
allowed entirely arbitrary. For instance, I've seen
templates that create only the head, a single row, or the
foot for a table. When the user wants to change the table,
they click edit, and not only does the software not have any
way of knowing that these consecutive template calls are
related.*
*
  o *Embedded page logic:* Template functions are not visually
representable in any way I've ever seen that would make any
sense to a non-programmer, yet they often have a profound
impact on the content of the page. Nesting a series of if
statements is especially going to be a mess in a GUI.
* This is not to say I have no ideas or plans on how to solve these
  issues. We are actively making choices to pave the way for
  WYSIWYG, but a topic like this hasn't yet proven to be very useful
  in this process. So far I have only seen the same circle of
  "Editing wiki-text sucks!" -> "We need WYSIWYG!" -> "WYSIWYG is
  broken" -> "It must be wiki-text's fault!" -> "Let's change
  wiki-text" -> "But it's so easy to edit!" -> "No it's not! Editing
  wiki-text sucks" -> and so on... So, FYI, this is not a new or in
  anyway original chain of thought or conversation - it's not bad,
  it's just going to be seen as spam to most people on this list.
* The topic is supposed to be on Template Editing which is, at least
  in the way it's being proposed, a little less of a stale topic -
  so where is all the energy on that front? We have an XML format to
  design and complex problems to sort out. Help is really needed.
  Let's all take a look at the link provided at the beginning of
  this thread http://usability.wikimedia.org/wiki/Template_forms

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Links to Wikipedia with .htm at the end

[Chris Down]

I believe that this is simply bad WYSIWYG editors at work.

- Chris

2009/9/24 Nikola Smolenski 

> I have noticed that a number (hundreds) of links to Wikipedia exist
> that are of the form http://xx.wikipedia.org/wiki/whatever.htm See this
> Google search for an overview:
> http://www.google.com/search?hl=en&q=%22wikipedia.org%2Fwiki+*+htm%22
>
> Is this way of linking a consequence of some bad editing tools appending
> .htm automatically, or were these links once actually valid? If they
> were, should they somehow be made to continue working? I saw at least
> one printed scientific work using such a link:
> http://scindeks.nb.rs/article.aspx?artid=0353-79190804835R&lang=en cites
> http://Wikipedia.org/wiki/contraception.htm
>
> On a related note, an interesting example I noticed in
> http://www.library.ait.ac.th/ThesisSearch/summary/Debajit%20Dutta.pdf
> that links to www.wiki.wikipedia.org/wiki/urban_heat_island.htm - did
> this www.wiki.wikipedia.org server really exist?
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Gerard Meijssen]

Hoi,
This specific character mentioned in the article is used to write the
Tanimuca-Retuarã language. This is specified in the article. itself.
Languages that need characters that are missing in fonts that are in general
use are not isolated affairs. In the end there is only one solution; we
should be part of a solution that allows us to show all characters.
Thanks,
 GerardM

2009/9/25 Aryeh Gregor

>

> On Fri, Sep 25, 2009 at 9:36 AM, Gerard Meijssen
>  wrote:
> > The notion that our editors should decide if a font is well enough
> > supported  is a bit off. It is saying "you cannot properly write your
> > language because ...".
>
> No, it's not.  We're talking about a specific article on the English
> Wikipedia about a single obscure character, and related cases where
> isolated characters don't display properly.  Nothing I said should be
> construed to have any bearing on radically different situations, such
> as an entire wiki whose language is poorly supported on common
> platforms.  While I appreciate that you take a great interest in
> technical topics related to internationalization, this is not such a
> topic.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)

[Aryeh Gregor]

On Fri, Sep 25, 2009 at 11:41 AM, Tim Starling  wrote:
> I think it makes sense to provide some way to modify the DOM after the
> base skin is finished making HTML. Some things can be done with CSS,
> but you don't want to be making heavy use of #id:after{content:"..."}
> to add in some advertising or analytics HTML.

Adding content is no problem.  Just provide a bunch of places where
arbitrary HTML can be injected by configuration.  The particular cases
of Analytics and ads should be cross-skin anyway, and currently you'd
be best off doing them using hooks (that's how I do Analytics on my
wiki).  What are use-cases for *skins* being able to alter the HTML
output, at anywhere near the level of precision provided by XSLT?

> And some modifications
> are quite arcane, like reordering boxes by switching them from
> ordinary floats to carefully constructed absolute positioning.

That's true, yes.  Later versions of CSS look like they'll provide
saner ways to do things, but we're a ways off from being able to use
any of those yet.  (The advanced positioning stuff in CSS3 isn't even
close to finished AFAIK, let alone widely implemented.)

> The template engine libraries are slow, and PHP with embedded HTML
> (like MonoBook) leads to code which is scary from a security
> perspective due to the difficulty of reviewing the many echo
> statements. And it doesn't solve the problem, because you end up with
> migration issues when you need to add more items to the output or
> change the existing items in some fundamental way.

I don't think there's any way to entirely avoid migration issues.
You'd have migration issues with XSLT too, the same way we have
JavaScript that breaks when we add a wrapper div or reorder some
things.  The best you can do is localize the damage, so things only
break if they changed that exact bit of HTML.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Aryeh Gregor]

On Fri, Sep 25, 2009 at 9:36 AM, Gerard Meijssen
 wrote:
> The notion that our editors should decide if a font is well enough
> supported  is a bit off. It is saying "you cannot properly write your
> language because ...".

No, it's not.  We're talking about a specific article on the English
Wikipedia about a single obscure character, and related cases where
isolated characters don't display properly.  Nothing I said should be
construed to have any bearing on radically different situations, such
as an entire wiki whose language is poorly supported on common
platforms.  While I appreciate that you take a great interest in
technical topics related to internationalization, this is not such a
topic.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Template editing

[Roan Kattouw]

2009/9/25 Magnus Manske :
> As to the issue of getting possible template variable names: Why not
> * load the wikitext of the template in the background
> * remove all nowiki, noinclude, etc
> * get everything that looks like "{{{NAME|" or "{{{NAME}}}"
> * remove known magic words
> * Profit!
>
We (the usability team) do intend to get 'content folding' (folding
template calls and tables into stubs that can be expanded at will)
done in the Citron (third) release.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Template editing

[Magnus Manske]

IMHO the question, in this case, is not "how to build the perfect
wikitext grammar/parser", but how to ease editing of wikitext through
editor enhancements. For that, it seems sufficient to cover the vast
majority of cases instead of writing a perfect solution, as long as it
falls back to "ugly" wikitext when in doubt. Having 1% of templates
appear in all their ugliness is better than 100%.

To that end, I have just written some proof-of-concept JavaScript:
http://en.wikipedia.org/wiki/User:Magnus_Manske/tmpl.js

It is not a solution, but shows a possible approach (example text to
use: [[Picopict]]):
* On edit start, it finds all templates in wikitext
* It does so only in namespace 0, so no template variables need to be
considered (otherwise, move the damned text out of article namespace!
;-)
* It will not touch templates that have no parameter - {{reflist}} is
easy enough
* It will replace all other templates with strings like
##TEMPLATEnumber:name##, e.g., ##TEMPLATE1:Infobox VG##
* These will be replaced with the original text again on save/preview/diff
* Double-clicking on, say, TEMPLATE1 will select that entire word. If
it is a template placeholder, an action is performed. For this demo,
it only shows the original text of the template (note that nested
templates are left as wikitext).

Obviously, this can be expanded to call up an editor of some kind. I
don't want to write one now that JQuery is around the corner :-)

And yes, I am introducing new syntax. That's not the point here; could
just as well be some other, pretty placeholder in a wysiwyg editor.


As to the issue of getting possible template variable names: Why not
* load the wikitext of the template in the background
* remove all nowiki, noinclude, etc
* get everything that looks like "{{{NAME|" or "{{{NAME}}}"
* remove known magic words
* Profit!


Cheers,
Magnus

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)

[Tim Starling]

Aryeh Gregor wrote:
> On Fri, Sep 25, 2009 at 1:19 AM, Tim Starling  wrote:
>> On this point, I think we need:
>> * Easier management of non-PHP skins (i.e. CSS and images only)
>> * Automated CSS generation (per original post)
>> * Easier ways to modify the document structure, with less PHP
>> involved. XSLT?
>> * An interface in PHP that we can live with, so we don't feel obliged
>> to keep breaking it.
> 
> XSLT is a non-starter unless we want fatal errors (or at least the
> skin completely breaking) on pages where we emit malformed XML.  And
> there always have been some of those, and probably always will be.
> Probably even more significantly, XSLT is a programming language and a
> rather obscure one.  If we're going to make MediaWiki skins so hard to
> make, we may as well stick with just requiring that they be in PHP.

I think it makes sense to provide some way to modify the DOM after the
base skin is finished making HTML. Some things can be done with CSS,
but you don't want to be making heavy use of #id:after{content:"..."}
to add in some advertising or analytics HTML. And some modifications
are quite arcane, like reordering boxes by switching them from
ordinary floats to carefully constructed absolute positioning.

You can do DOM manipulation in PHP, I just thought that using a more
restricted language might help avoid some of the migration issues that
keep coming up.

> The standard way to handle skinning in web apps, AFAICT, is to chop
> the interface up into templates, and stitch them together at runtime.
> Then skinners can modify the templates one by one, and on upgrade they
> only have to merge changes for the templates they've changed.  Which
> is still a huge pain for even moderate customizations, as I can attest
> from personal experience.  But it has the advantage that skinners only
> need to modify HTML and CSS, not PHP or XSLT or whatnot.

The template engine libraries are slow, and PHP with embedded HTML
(like MonoBook) leads to code which is scary from a security
perspective due to the difficulty of reviewing the many echo
statements. And it doesn't solve the problem, because you end up with
migration issues when you need to add more items to the output or
change the existing items in some fundamental way.

I mentioned the fact that Wordpress accelerates loading by moving
scripts to the bottom of the page, I didn't mention that it only works
for properly maintained skins since many Wordpress skins don't call
the correct footer function.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data Processing

[Petr Kadlec]

2009/9/25 李琴 :
> The entire page text has been stroed in text table. But the recent change
> page just shows the edited text.
> Then,how do these text stroed?

It is not stored. It is evaluated during every diff view by comparing
(diffing) the two revisions (see phase3/includes/diff/*.php). Note you
can view differences between two non-consecutive versions (indeed, you
can compare two revisions not even belonging to the same page, e.g.
http://en.wikipedia.org/wiki/?diff=12345&oldid=67890&diffonly=1).

> I want to see the content(BLOB) of  old_text fiels in text table.
>  What should I do?

It depends on the configuration of your wiki. The “text” table might
contain the wikitext directly in the “old_text” column (in the source
text form, or as a serialized PHP object, see
phase3/includes/HistoryBlob.php), or the “old_text” column is only a
pointer to where/how the text is really stored, see e.g.
http://www.mediawiki.org/wiki/Manual:External_Storage

-- [[cs:User:Mormegil | Petr Kadlec]]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Mark Clements (HappyDog)]

Jared Williams wrote:
> The problem is the ambiguity with italics, (''italics''). So the
> current parser doesn't really make its final decision on
> what should be bold or what should be italic until it hits a
> newline.  If there are an even number of both bold and italics
> then it assumes it interpreted the line correctly.
[SNIP]
> I think this is part of what makes wikitext undescribable
> in a formal grammar.

And he also wrote:
> Problem is quotes are also valid as part of the textual content, so
> could not italics immediately before or after an apostrophe. As in
>
> L'''arc de triomphe''
>
> Which the current parser resolves to L'arc de triomphe

There lies one of the main problems with parsing wikitext - that it uses a 
wide range of standard text characters to implement it's markup.  In HTML, 
there are basically two (< and >) plus an escape character (&).  Therefore 
HTML can in theory[1] consist of "Any text you like, with <, > and & 
replaced by < > and & respectively" with two special markup 
symbols ( and &escaped_entity;).  No room for ambiguity 
there, and only minimal translation required to convert plain-text to a 
format suitable for use in an HTML document.

In MediaWiki, just taking that single ' character as an example, it could be 
one of several punctuation symbols (apostrophe, single-quote, prime, etc.) 
or it could be part of an opening italic tag, a closing italic tag, an 
opening bold tag, or a closing bold tag.  As far as I understand, it is 
impossible to deal effectively with this massive overloading of the 
apostrophe character without the kind of special logic we have in place 
already (as described by Jared).  To take his example one step further, 
here's something to really throw a formal grammar-based parser, but which 
our parser handles just fine: '''Photo of L'''arc de triomphe'' by 'John

- Mark Clements (HappyDog)

[1] I'm ignoring all the document-structure requirements, plus 
character-encoding issues, etc. that complicate things a bit. 



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Nikola Smolenski]

Jared Williams wrote:
> Problem is quotes are also valid as part of the textual content, so
> could not italics immediately before or after an apostrophe. As in
> 
> L'''arc de triomphe''
> 
> Which the current parser resolves to L'arc de triomphe

What I am going to say is going to be the worst heresy, but could this 
problem be solved by gradually migrating to a new wiki markup, for 
example **bold** and //italic//? This markup is more logical and easier 
to remember, more used outside of MediaWiki (unofficial email markup is 
similar) and more easily visible than apostrophe markup, and I never 
understood how the apostrophes came to be in the first place. The most 
important for this discussion - it also has much less potential to 
confuse the parser.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] JS2 design (was Re: Working towards branching MediaWiki 1.16)

[Aryeh Gregor]

On Fri, Sep 25, 2009 at 1:19 AM, Tim Starling  wrote:
> On this point, I think we need:
> * Easier management of non-PHP skins (i.e. CSS and images only)
> * Automated CSS generation (per original post)
> * Easier ways to modify the document structure, with less PHP
> involved. XSLT?
> * An interface in PHP that we can live with, so we don't feel obliged
> to keep breaking it.

XSLT is a non-starter unless we want fatal errors (or at least the
skin completely breaking) on pages where we emit malformed XML.  And
there always have been some of those, and probably always will be.
Probably even more significantly, XSLT is a programming language and a
rather obscure one.  If we're going to make MediaWiki skins so hard to
make, we may as well stick with just requiring that they be in PHP.

The standard way to handle skinning in web apps, AFAICT, is to chop
the interface up into templates, and stitch them together at runtime.
Then skinners can modify the templates one by one, and on upgrade they
only have to merge changes for the templates they've changed.  Which
is still a huge pain for even moderate customizations, as I can attest
from personal experience.  But it has the advantage that skinners only
need to modify HTML and CSS, not PHP or XSLT or whatnot.

As it happens, most of the essential differences between skins can be
reproduced using only CSS, if you know enough CSS.  I once personally
wrote, in about an hour, some CSS that made Monobook look almost
pixel-for-pixel identical to Modern, with no HTML changes.  The only
problem is I didn't bother fixing IE, so it wasn't committable.  I
don't think almost any reskin should need to change the HTML at all,
except maybe to add classes and such (which can be done in core).  It
should only be necessary if you really want to change how the
interface behaves somehow (like having extra buttons), rather than
just how it looks.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data Processing

[李琴]

The entire page text has been stroed in text table. But the recent change 
page just shows the edited text.
Then,how do these text stroed? 


I want to see the content(BLOB) of  old_text fiels in text table.
 What should I do?


Thanks


-Original Message-
From: Petr Kadlec 
To: Wikimedia developers 
Date: Fri, 25 Sep 2009 14:06:41 +0200
Subject: Re: [Wikitech-l] Data Processing
2009/9/25 李琴 :
>   If i just edit a page's section.Then ,What will be saved in the text
> table,  the entire page's text or  just the edited section's text   ?

The entire page text, which is the result of merging the previous page
text with the changes you’ve made to the section.

> Why the text table's fiels are old_id, old_text,old_flags? What does
> the old mean?

See http://www.mediawiki.org/wiki/Manual:Text_table

-- [[cs:User:Mormegil | Petr Kadlec]]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Gerard Meijssen]

Hoi,
The notion that our editors should decide if a font is well enough
supported  is a bit off. It is saying "you cannot properly write your
language because ...".

I do appreciate that TECHNICALLY you are right. However what is needed is
people adding the "new" glyphs to the font. This is no rocket science.. we
can do this.
Thanks,
   GerardM

2009/9/25 Aryeh Gregor

>

> On Thu, Sep 24, 2009 at 6:58 PM, Steve Bennett 
> wrote:
> > I'm using Chrome 3.0.195.21, and have long found that some characters
> > in Wikipedia render as boxes. One example:
> > http://en.wikipedia.org/wiki/P_with_stroke renders as "
> > (minuscule: )..."
>
> As the article says, the characters were only added to Unicode in 2005
> and 2006.  It's to be expected that even good Unicode fonts might not
> yet support them.  The article even notes that few fonts support the
> characters.
>
> > Now, I looked at http://en.wikipedia.org/wiki/Help:Special_characters
> > and the advice is not very useful or specific: it says that "Special
> > symbols should display properly without further configuration with ...
> > Safari and most other recent browsers." I tried installing Gnu Unifont
> > and setting it as the default browser font, but that seems to be
> > overridden by MediaWiki anyway?
>
> No, GNU Unifont probably just doesn't have those characters.  The
> default fonts on Ubuntu seem to have the majuscule but not the
> minuscule (or at least that's how Chrome and Firefox both render the
> page).
>
> > So anyway, I'm asking two questions:
> > 1) What can I do to get more special characters to render correctly in
> Chrome?
>
> Get better fonts.  Realistically, you should do this by waiting a few
> years until your preinstalled fonts hopefully support the character.
>
> > 2) Could/would anyone improve [[Help:Special characters]] to make it
> > clearer, more specific and correct?
>
> It needs to note that there's no font out there that really supports
> *all* of Unicode, especially since Unicode keeps changing.  Wikipedia
> editors need to decide on a case-by-case basis whether a Unicode
> character is supported widely enough to justify using it in an
> article's text, or whether an image should be used instead.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikitext vs. WYSIWYG (was: Proposal for editing template calls within pages)

[Aryeh Gregor]

On Thu, Sep 24, 2009 at 8:34 PM, Jacopo Corbetta
 wrote:
> (HTML-style headings do not show up in the TOC, an odd
> wikitext feature which we surely don't want newbies to use).

HTML-style headings do show up in the TOC, and have for a few years as
far as I know.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unicode characters in Chrome

[Aryeh Gregor]

On Thu, Sep 24, 2009 at 6:58 PM, Steve Bennett  wrote:
> I'm using Chrome 3.0.195.21, and have long found that some characters
> in Wikipedia render as boxes. One example:
> http://en.wikipedia.org/wiki/P_with_stroke renders as "
> (minuscule: )..."

As the article says, the characters were only added to Unicode in 2005
and 2006.  It's to be expected that even good Unicode fonts might not
yet support them.  The article even notes that few fonts support the
characters.

> Now, I looked at http://en.wikipedia.org/wiki/Help:Special_characters
> and the advice is not very useful or specific: it says that "Special
> symbols should display properly without further configuration with ...
> Safari and most other recent browsers." I tried installing Gnu Unifont
> and setting it as the default browser font, but that seems to be
> overridden by MediaWiki anyway?

No, GNU Unifont probably just doesn't have those characters.  The
default fonts on Ubuntu seem to have the majuscule but not the
minuscule (or at least that's how Chrome and Firefox both render the
page).

> So anyway, I'm asking two questions:
> 1) What can I do to get more special characters to render correctly in Chrome?

Get better fonts.  Realistically, you should do this by waiting a few
years until your preinstalled fonts hopefully support the character.

> 2) Could/would anyone improve [[Help:Special characters]] to make it
> clearer, more specific and correct?

It needs to note that there's no font out there that really supports
*all* of Unicode, especially since Unicode keeps changing.  Wikipedia
editors need to decide on a case-by-case basis whether a Unicode
character is supported widely enough to justify using it in an
article's text, or whether an image should be used instead.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data Processing

[Petr Kadlec]

2009/9/25 李琴 :
>       If i just edit a page's section.Then ,What will be saved in the text
> table,  the entire page's text or  just the edited section's text   ?

The entire page text, which is the result of merging the previous page
text with the changes you’ve made to the section.

>     Why the text table's fiels are old_id, old_text,old_flags? What does
> the old mean?

See http://www.mediawiki.org/wiki/Manual:Text_table

-- [[cs:User:Mormegil | Petr Kadlec]]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[David Gerard]

2009/9/25 Dmitriy Sintsov :

> XML is used to store "human-produced" rich formatted text by many
> standalone and web apps. XML parsers are also very strict and spitting
> errors. As it's been mentioned recently, XML is really good for bots,
> too, for that reason (the input is "error-free" tree).
> I wonder, If the browsers can handle tag soup, most probably MediaWiki
> parser can handle wikitext soup, too? Eg, instead of parsing error,
> properly close the nodes. The existing wikitext of millions of articles
> has to be converted by commandline upgrade script in case the wikitext
> will be abandoned. Though I wonder whether it's possible to keep
> wikitext editing mode for backwards compatibility by using the same
> method online.


Wikitext started as a shorthand for HTML. The horrible things that
have happened since then are from ad-hoc additions to a parser and no
formal spec, leaving the parser behaviour as, literally, the only
definition.


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Dmitriy Sintsov]

* David Gerard  [Fri, 25 Sep 2009 11:59:04 +0100]:
> 2009/9/25 Roan Kattouw :
>
> In past discussions I have noted that "tag soup" is a *feature* of
> human languages, not a bug.
>
> HTML was constructed as a computer markup language for humans.
> Unfortunately, the humans in question were nuclear physicists; lesser
> beings couldn't handle it.
>
> Note how HTML5 now defines how to handle "bad" syntax, in recognition
> of the fact that humans write tag soup.
>
> Wikitext spitting errors would be a bug in wikitext, not a feature.
>
XML is used to store "human-produced" rich formatted text by many 
standalone and web apps. XML parsers are also very strict and spitting 
errors. As it's been mentioned recently, XML is really good for bots, 
too, for that reason (the input is "error-free" tree).
I wonder, If the browsers can handle tag soup, most probably MediaWiki 
parser can handle wikitext soup, too? Eg, instead of parsing error, 
properly close the nodes. The existing wikitext of millions of articles 
has to be converted by commandline upgrade script in case the wikitext 
will be abandoned. Though I wonder whether it's possible to keep 
wikitext editing mode for backwards compatibility by using the same 
method online.
Dmitriy

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data Processing

[李琴]

   If i just edit a page's section.Then ,What will be saved in the text 
table,  the entire page's text or  just the edited section's text   ?
   
 Why the text table's fiels are old_id, old_text,old_flags? What does 
the old mean?
  
Thanks 


-Original Message-
From: Bryan Tong Minh 
To: Wikimedia developers 
Date: Fri, 25 Sep 2009 12:31:15 +0200
Subject: Re: [Wikitech-l] Data Processing


On Fri, Sep 25, 2009 at 12:28 PM, 李琴  wrote:
> OK,  I see. And the other questions?
>
> If I edit a page,Whether the page_id change or not?
>
page_latest will point to the relevant rev_id. The text will most
likely be saved in the text table. Article::doEdit and Revision are
the most likely places in the source to start looking for more
information.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data Processing

[Roan Kattouw]

2009/9/25 李琴 :
> OK,  I see. And the other questions?
>
> If I edit a page,Whether the page_id change or not?
>
No, the page_id stays the same when pages are edited, and even when
they're moved (in the latter case, page_namespace and/or page_title
will change, of course).

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[David Gerard]

2009/9/25 Roan Kattouw :

> The point is that wikitext doesn't *have* parsing errors. The parser
> is very tolerant in that it tries to resolve 'invalid' and ambiguous
> constructs by some combination of guessing what was probably intended
> and trying not to mess up the rest of the article (the newline thing
> mentioned earlier fall in the latter category). I agree that this
> probably causes the weird quirks that make wikitext such a horribly
> complex language to define and parse, so I think a good way to
> continue this discussion would be to talk about how invalid, ambiguous
> and otherwise unexpected input should be handled.


In past discussions I have noted that "tag soup" is a *feature* of
human languages, not a bug.

HTML was constructed as a computer markup language for humans.
Unfortunately, the humans in question were nuclear physicists; lesser
beings couldn't handle it.

Note how HTML5 now defines how to handle "bad" syntax, in recognition
of the fact that humans write tag soup.

Wikitext spitting errors would be a bug in wikitext, not a feature.


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Jared Williams]

 

> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org 
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of 
> Dmitriy Sintsov
> Sent: 25 September 2009 11:09
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] Proposal for editing template calls 
> within pages
> 
> * Jared Williams  [Fri, 25 Sep 2009
> 10:49:54 +0100]:
> >
> > The problem is the ambiguity with italics, (''italics''). So the 
> > current parser doesn't really make its final decision on 
> what should 
> > be bold or what should be italic until it hits a newline. 
> If there are 
> > an even number of both bold and italics then it assumes it 
> interpreted 
> > the line correctly.
> >
> > However if there is an uneven number of bold & italic, it starts 
> > searching for where it could have misinterpreted something.
> >
> Shouldn't these cases be considered a syntax error? How much 
> is common to wikipedia to have uneven numbers of occurences 
> of that? Is there any use for that (weird templates)?
> 
> > I think this is part of what makes wikitext undescribable 
> in a formal 
> > grammar.
> >
> > Jared
> >
> Let's assume an odd occurence of ''' will be converted to 
>  and an even occurence ''' to  
> (begin/end of the node)? Non-paired occurence will simply 
> cause XML parsing error - there should not be uneven number 
> of '' or '''.
> Dmitriy
> 

Problem is quotes are also valid as part of the textual content, so
could not italics immediately before or after an apostrophe. As in

L'''arc de triomphe''

Which the current parser resolves to L'arc de triomphe

Jared


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Special:UploadMogile

[Bryan Tong Minh]

Does anybody actually use Special:UploadMogile? Should we try to fix
it to work with the new upload code or just get rid of it?


Bryan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data Processing

[Bryan Tong Minh]

On Fri, Sep 25, 2009 at 12:28 PM, 李琴  wrote:
> OK,  I see. And the other questions?
>
> If I edit a page,Whether the page_id change or not?
>
page_latest will point to the relevant rev_id. The text will most
likely be saved in the text table. Article::doEdit and Revision are
the most likely places in the source to start looking for more
information.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data Processing

[李琴]

OK,  I see. And the other questions?

If I edit a page,Whether the page_id change or not?
 


-Original Message-
From: Petr Kadlec 
To: Wikimedia developers 
Date: Fri, 25 Sep 2009 11:30:34 +0200
Subject: Re: [Wikitech-l] Data Processing


2009/9/25 vanessa lee :
> What form are articles  stored in database?

Raw wiki text, plus many tables containing metadata. See
http://www.mediawiki.org/wiki/Manual:Database_layout

-- [[cs:User:Mormegil | Petr Kadlec]]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Roan Kattouw]

2009/9/25 Dmitriy Sintsov :
> Let's assume an odd occurence of ''' will be converted to  and
> an even occurence ''' to  (begin/end of the node)? Non-paired
> occurence will simply cause XML parsing error - there should not be
> uneven number of '' or '''.
>
The point is that wikitext doesn't *have* parsing errors. The parser
is very tolerant in that it tries to resolve 'invalid' and ambiguous
constructs by some combination of guessing what was probably intended
and trying not to mess up the rest of the article (the newline thing
mentioned earlier fall in the latter category). I agree that this
probably causes the weird quirks that make wikitext such a horribly
complex language to define and parse, so I think a good way to
continue this discussion would be to talk about how invalid, ambiguous
and otherwise unexpected input should be handled.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Dmitriy Sintsov]

* Jared Williams  [Fri, 25 Sep 2009 
10:49:54 +0100]:
>
> The problem is the ambiguity with italics, (''italics''). So the
> current parser doesn't really make its final decision on what should
> be bold or what should be italic until it hits a newline. If there are
> an even number of both bold and italics then it assumes it interpreted
> the line correctly.
>
> However if there is an uneven number of bold & italic, it starts
> searching for where it could have misinterpreted something.
>
Shouldn't these cases be considered a syntax error? How much is common 
to wikipedia to have uneven numbers of occurences of that? Is there any 
use for that (weird templates)?

> I think this is part of what makes wikitext undescribable in a formal
> grammar.
>
> Jared
>
Let's assume an odd occurence of ''' will be converted to  and 
an even occurence ''' to  (begin/end of the node)? Non-paired 
occurence will simply cause XML parsing error - there should not be 
uneven number of '' or '''.
Dmitriy

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[David Gerard]

2009/9/25 Dmitriy Sintsov :

> You haven't convinced me. I am not the most bright person in the world
> (my coding skills aren't top - I am more of humanitarian brain person
> actually) but it was really easy to me to understand basics of wikitext.
> Just in few minutes. Also, such repeated single markup characters are
> faster to type than choosing formatting with GUI. I like wikitext.


At this point in the discussion, I'm thankful you're not the person
who needs to be convinced.


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Jared Williams]

 

> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org 
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of 
> Dmitriy Sintsov
> Sent: 25 September 2009 07:01
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] Proposal for editing template calls 
> within pages
> 
> * Aryeh Gregor  [Thu, 24 Sep 2009
> 15:40:46 -0400]:
> > Templates and refs are by far the worst offenders, for 
> sticking tons 
> > of content in the page that doesn't have any obvious 
> relationship to 
> > the actual content.  Getting rid of them would be a huge 
> step forward.
> >  But stuff like '''bold''' and ==headings== are also a real
problem.
> What's complex in '''bold''' and ==headings== ? Here when 
> we've installed the wiki for local "historical records" at 
> the local Russian university the humanitarians got to 
> understand such things really quickly. The Ms or PhD in 
> History cannot be that much stupid.. To me it looks like you 
> are overstating the complexity of the wikitext. But yes, they 
> are calling technical staff for complex cases, but it happens 
> _rarely_. Historical records are mostly just plain text with 
> links and occasional pictures.

The problem is the ambiguity with italics, (''italics''). So the
current parser doesn't really make its final decision on what should
be bold or what should be italic until it hits a newline. If there are
an even number of both bold and italics then it assumes it interpreted
the line correctly.

However if there is an uneven number of bold & italic, it starts
searching for where it could have misinterpreted something. 

I think this is part of what makes wikitext undescribable in a formal
grammar.

Jared


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data Processing

[Petr Kadlec]

2009/9/25 vanessa lee :
> What form are articles  stored in database?

Raw wiki text, plus many tables containing metadata. See
http://www.mediawiki.org/wiki/Manual:Database_layout

-- [[cs:User:Mormegil | Petr Kadlec]]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Happy-melon]

"David Gerard"  wrote in message 
news:fbad4e140909241512h5c56dd09xe6d3d7de0603f...@mail.gmail.com...
> 2009/9/24 Platonides :
>> Brian wrote:
>
>>> * wikitext parsing would be much faster if the language was well defined 
>>> and
>>> we could use flex/bison/etc...
>
>> Have you read the archives?
>> It has been tried. Several times.
>> There's even a mailing list for that.
>> Getting a formal definition of ~90% of the wikitext syntax is easy. The
>> other 10% drived nuts everyone trying to do it hard enough, so far.
>> Keep trying, but build over what's already done.


The 10% drove people off cliffs because it is, pretty much by definition, 
the horrible unexpected behaviour that is a *consequence* of not having a 
formal definition.  Writing a formal definition is not impossible if you 
require that it be sensible at the final reading.  The parser is, in many 
places, *not* sensible, and naturally those quirks are difficult to 
describe, but they're also undesirable overall.  A true move to a formal 
language definition involves action from both ends: writing a formal 
definition that follows the current parser in general, *and* being prepared 
to alter the parser to remove some of the more egregious deviations from 
expected behaviour.

--HM
 



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for editing template calls within pages

[Dmitriy Sintsov]

* Steve Bennett  [Fri, 25 Sep 2009 16:13:51 +1000]:
> On Fri, Sep 25, 2009 at 4:00 PM, Dmitriy Sintsov 
> wrote:
> > What's complex in '''bold''' and ==headings== ? Here when we've
>
> It *looks* complex. That's pretty much most of the problem. Here's our
> desired use case:
>
You haven't convinced me. I am not the most bright person in the world 
(my coding skills aren't top - I am more of humanitarian brain person 
actually) but it was really easy to me to understand basics of wikitext. 
Just in few minutes. Also, such repeated single markup characters are 
faster to type than choosing formatting with GUI. I like wikitext.

Anyway, the displays have a large resolution nowadays. What about 
splitting edit page in two areas? One for entering wikitext with syntax 
highlighting and another one - an AJAX generated on-the-fly preview how 
would it looks like after the save. Such way, the learning curve would 
be much lower.

But I probably will stop arguing, because my opinion is hardly 
representative.
Dmitriy

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l