Re: [Wikitech-l] Proposal for editing template calls within pages
* Aryeh Gregor simetrical+wikil...@gmail.com [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. Everything unexpected like that is going to increase the risk that a new user will get worried he doesn't know what he's doing, and give up rather than risk breaking something or put effort into figuring out what to do. If you give *anyone*[1] a WYSIWYG interface, they'll know how it works, because they're used to it from Word and whatnot. That's just not true of wikitext, no matter how simple it is once you *already* understand it. Maybe, but it would be nice if source wikitext will remain as aliernative. Anyway, you're the head developers, it's upon you. 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
On Fri, Sep 25, 2009 at 4:00 PM, Dmitriy Sintsov ques...@rambler.ru 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: 1) User views a page that is deficient in some way. 2) User decides to edit. 3) User edits. 4) User has improved the world. Here's our actual use case. 1) User views a page that is deficient in some way. 2) User has no idea they can edit. Ok, moving on... 2) User decides to edit. 3) User sees wikitext. 4) User runs screaming. The Ms or PhD in History cannot be that much stupid. We're not in a position to offer training to our potential end users. Steve ___ 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
* Steve Bennett stevag...@gmail.com [Fri, 25 Sep 2009 16:13:51 +1000]: On Fri, Sep 25, 2009 at 4:00 PM, Dmitriy Sintsov ques...@rambler.ru 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
Re: [Wikitech-l] Proposal for editing template calls within pages
David Gerard dger...@gmail.com wrote in message news:fbad4e140909241512h5c56dd09xe6d3d7de0603f...@mail.gmail.com... 2009/9/24 Platonides platoni...@gmail.com: 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
-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 simetrical+wikil...@gmail.com [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] Proposal for editing template calls within pages
2009/9/25 Dmitriy Sintsov ques...@rambler.ru: 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] Data Processing
2009/9/25 vanessa lee q...@ica.stc.sh.cn: 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
* Jared Williams jared.willia...@ntlworld.com [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 wmf:bold and
an even occurence ''' to /wmf:bold (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
2009/9/25 Dmitriy Sintsov ques...@rambler.ru: Let's assume an odd occurence of ''' will be converted to wmf:bold and an even occurence ''' to /wmf:bold (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] 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 petr.kad...@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Date: Fri, 25 Sep 2009 11:30:34 +0200 Subject: Re: [Wikitech-l] Data Processing 2009/9/25 vanessa lee q...@ica.stc.sh.cn: 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] Data Processing
On Fri, Sep 25, 2009 at 12:28 PM, 李琴 q...@ica.stc.sh.cn 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] Special:UploadMogile
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] Proposal for editing template calls within pages
-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 jared.willia...@ntlworld.com [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
wmf:bold and an even occurence ''' to /wmf:bold
(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'iarc de triomphe/i
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
2009/9/25 Roan Kattouw roan.katt...@gmail.com: 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
2009/9/25 Dmitriy Sintsov ques...@rambler.ru: 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] Data Processing
2009/9/25 李琴 q...@ica.stc.sh.cn: 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] Unicode characters in Chrome
On Thu, Sep 24, 2009 at 6:58 PM, Steve Bennett stevag...@gmail.com 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 box (minuscule: box)... 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] Wikitext vs. WYSIWYG (was: Proposal for editing template calls within pages)
On Thu, Sep 24, 2009 at 8:34 PM, Jacopo Corbetta jacopo.corbe...@gmail.com 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
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 simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com On Thu, Sep 24, 2009 at 6:58 PM, Steve Bennett stevag...@gmail.com 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 box (minuscule: box)... 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] 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 petr.kad...@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Date: Fri, 25 Sep 2009 14:06:41 +0200 Subject: Re: [Wikitech-l] Data Processing 2009/9/25 李琴 q...@ica.stc.sh.cn: 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] JS2 design (was Re: Working towards branching MediaWiki 1.16)
On Fri, Sep 25, 2009 at 1:19 AM, Tim Starling tstarl...@wikimedia.org 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] Proposal for editing template calls within pages
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'iarc de triomphe/i
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 lt; gt; and amp; respectively with two special markup
symbols (markup goes here 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] Data Processing
2009/9/25 李琴 q...@ica.stc.sh.cn: 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=12345oldid=67890diffonly=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] JS2 design (was Re: Working towards branching MediaWiki 1.16)
Aryeh Gregor wrote:
On Fri, Sep 25, 2009 at 1:19 AM, Tim Starling tstarl...@wikimedia.org 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
[Wikitech-l] Template editing
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] Template editing
2009/9/25 Magnus Manske magnusman...@googlemail.com:
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
Re: [Wikitech-l] Unicode characters in Chrome
On Fri, Sep 25, 2009 at 9:36 AM, Gerard Meijssen gerard.meijs...@gmail.com 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] JS2 design (was Re: Working towards branching MediaWiki 1.16)
On Fri, Sep 25, 2009 at 11:41 AM, Tim Starling tstarl...@wikimedia.org 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
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 simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com On Fri, Sep 25, 2009 at 9:36 AM, Gerard Meijssen gerard.meijs...@gmail.com 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] Links to Wikipedia with .htm at the end
I believe that this is simply bad WYSIWYG editors at work. - Chris 2009/9/24 Nikola Smolenski smole...@eunet.rs 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=enq=%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-79190804835Rlang=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] Proposal for editing template calls within pages
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] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal tpars...@wikimedia.orgwrote: * 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] Links to Wikipedia with .htm at the end
On Thu, Sep 24, 2009 at 5:18 AM, Nikola Smolenski smole...@eunet.rs 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=enq=%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-79190804835Rlang=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] JS2 design (was Re: Working towards branching MediaWiki 1.16)
On Fri, 25 Sep 2009 09:48:04 -0400, Aryeh Gregor wrote: On Fri, Sep 25, 2009 at 1:19 AM, Tim Starling tstarl...@wikimedia.org 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] Proposal for editing template calls within pages
2009/9/25 Brian brian.min...@colorado.edu: 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] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 1:49 PM, Roan Kattouw roan.katt...@gmail.comwrote: 2009/9/25 Brian brian.min...@colorado.edu: 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
On Fri, Sep 25, 2009 at 2:03 PM, Brian brian.min...@colorado.edu wrote: On Fri, Sep 25, 2009 at 1:49 PM, Roan Kattouw roan.katt...@gmail.comwrote: 2009/9/25 Brian brian.min...@colorado.edu: 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 wrote: On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal tpars...@wikimedia.orgwrote: * 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]http://strategy.wikimedia.org/wiki/Process#Timeline_.282009_-_2010.29 -- 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
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 roan.katt...@gmail.com wrote: 2009/9/25 Brian brian.min...@colorado.edu: 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
On Fri, Sep 25, 2009 at 2:14 PM, Alex mrzmanw...@gmail.com wrote: Brian wrote: On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal tpars...@wikimedia.org 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]http://strategy.wikimedia.org/wiki/Process#Timeline_.282009_-_2010.29 -- 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 sgard...@wikimedia.org wrote: 2009/9/22 Eugene Eric Kim ee...@blueoxen.com: On Mon, Sep 14, 2009 at 3:49 PM, Pavlo Shevelo pavlo.shev...@gmail.com 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 a simple thing that looks sensible, and one person wants to, and is
Re: [Wikitech-l] Proposal for editing template calls within pages
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 Kattouwroan.katt...@gmail.com wrote: 2009/9/25 Brianbrian.min...@colorado.edu: 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
2009/9/25 Brian brian.min...@colorado.edu: 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
On Fri, Sep 25, 2009 at 2:20 PM, Roan Kattouw roan.katt...@gmail.comwrote: 2009/9/25 Brian brian.min...@colorado.edu: 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
2009/9/25 Brian brian.min...@colorado.edu: 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
Nikola Smolenski smolensk at 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
On Fri, Sep 25, 2009 at 2:42 PM, Roan Kattouw roan.katt...@gmail.comwrote: 2009/9/25 Brian brian.min...@colorado.edu: 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] Wikitext vs. WYSIWYG
Aryeh Gregor wrote: On Thu, Sep 24, 2009 at 8:34 PM, Jacopo Corbetta jacopo.corbe...@gmail.com 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
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] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 3:13 PM, Brion Vibber br...@wikimedia.org 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
2009/9/25 Brian brian.min...@colorado.edu: * 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] Unicode characters in Chrome
On Fri, Sep 25, 2009 at 1:53 PM, Gerard Meijssen gerard.meijs...@gmail.com 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
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 documentation tag extension, with the elements
defined as a list?
It would implicitely be noinclude
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:
documentation
*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|]].
/documentation
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:
documentation
*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.
/documentation
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] JS2 design (was Re: Working towards branching MediaWiki 1.16)
On Fri, Sep 25, 2009 at 3:46 PM, Steve Sanbeg ssan...@ask.com 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
On Fri, Sep 25, 2009 at 4:06 PM, Happy-melon happy-me...@live.com wrote: Brian brian.min...@colorado.edu 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
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
2009/9/25 Platonides platoni...@gmail.com: 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
On 9/25/09 3:39 PM, Roan Kattouw wrote: 2009/9/25 Platonidesplatoni...@gmail.com: 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
2009/9/26 Brian brian.min...@colorado.edu:
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
-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 platoni...@gmail.com: 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] JS2 design (was Re: Working towards branchingMediaWiki 1.16)
-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 ssan...@ask.com 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
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 new complex syntax. 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] Proposal for editing template calls within pages
On Fri, Sep 25, 2009 at 4:49 PM, Roan Kattouw roan.katt...@gmail.comwrote:
2009/9/26 Brian brian.min...@colorado.edu:
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 strategy,
led us to kludge something even worse on top.
Re: [Wikitech-l] Proposal for editing template calls within pages
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
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
On Fri, Sep 25, 2009 at 2:57 PM, Platonides platoni...@gmail.com 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. snip 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
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
On 9/25/09 6:11 PM, Robert Rohde wrote: On Fri, Sep 25, 2009 at 2:57 PM, Platonidesplatoni...@gmail.com 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. snip 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] JS2 design (was Re: Working towards branching MediaWiki 1.16)
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 the
