* Nikola Smolenski [Thu, 24 Sep 2009 08:44:28
+0200]:
> Having said that, I don't see why would XML be necessary. Table and
> template markup are well structured and could be used by any editor
just
> as XML would. Additionally, it is easier to observe diffs with wiki
> markup.
>
So it would be
On Thu, Sep 24, 2009 at 4:44 PM, Nikola Smolenski wrote:
> Having said that, I don't see why would XML be necessary. Table and
> template markup are well structured and could be used by any editor just
> as XML would. Additionally, it is easier to observe diffs with wiki markup.
Is it possible, c
On Thu, Sep 24, 2009 at 5:31 PM, Dmitriy Sintsov wrote:
> So it would be menu and icon-driven editing, where the hands should move
> from keyboard to mouse and vice versa, like MS Word. Not very handy for
> programmers and people who prefer to do most of tasks in command line.
I think you're maki
Steve Bennett wrote:
> On Thu, Sep 24, 2009 at 4:44 PM, Nikola Smolenski wrote:
>> Having said that, I don't see why would XML be necessary. Table and
>> template markup are well structured and could be used by any editor just
>> as XML would. Additionally, it is easier to observe diffs with wiki
Trevor Parscal wrote:
> If you are really doing a JS2 rewrite/reorganization, would it be
> possible for some of us (especially those of us who deal almost
> exclusively with JavaScript these days) to get a chance to ask
> questions/give feedback/help in general?
I've mostly been working on ana
Aryeh Gregor gmail.com> writes:
> Wikitext is not easy to edit.
It is easy enough to edit for power users, who make the large majority of edits;
and way more comfortable than WYSIWYG. Wikis require a certain hacker mentality
- not in the technical sense, but a desire to understand things in depth
Tim Starling wikimedia.org> writes:
> * Unnecessary use of the global namespace. The jQuery style is nice,
> with local functions inside an anonymous closure:
>
> function () {
>function setup() {
>...
>}
>addOnloadHook( setup );
> }();
This would make it impossible to overw
I have noticed that a number (hundreds) of links to Wikipedia exist
that are of the form http://xx.wikipedia.org/wiki/whatever.htm See this
Google search for an overview:
http://www.google.com/search?hl=en&q=%22wikipedia.org%2Fwiki+*+htm%22
Is this way of linking a consequence of some bad editi
2009/9/24 Tisza Gergő :
> It is easy enough to edit for power users, who make the large majority of
> edits;
> and way more comfortable than WYSIWYG.
Much as vim is more powerful than Notepad.
However, impenetrable wikitext is one of *the* greatest barriers to
new users on Wikimedia projects.
On Thu, Sep 24, 2009 at 14:36, David Gerard wrote:
> However, impenetrable wikitext is one of *the* greatest barriers to
> new users on Wikimedia projects. And this impenetrability is not, in
> any way whatsoever or by any twists of logic, a feature.
Adding a gui layer to wikitext is always okay
Also take into account on the javascript redesign, javascript wiki-side
extensions.
[[MediaWiki:Common.js]] importScripts [[MediaWiki:Wikiminiatlas.js]],
[[MediaWiki:niceGalleries.js]] and [[MediaWiki:buttonForRFA.js]], which
then load [[MediaWiki:buttonForRFA/lang.js]]... plus the several Gadgets
On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov wrote:
> So it would be menu and icon-driven editing, where the hands should move
> from keyboard to mouse and vice versa, like MS Word. Not very handy for
> programmers and people who prefer to do most of tasks in command line.
Programmers rank fa
Possibly-OFF-TOPIC-here
I see that ImageMagick can combine images in a single one.
A single image mean a single hit to a Apache, so it only have to spawn once.
On the clientside, a single image can draw multiple elements with some
ninja CSS stuff. ( background-position?).
For such thing to be
Tei wrote:
> Possibly-OFF-TOPIC-here
>
> I see that ImageMagick can combine images in a single one.
>
> A single image mean a single hit to a Apache, so it only have to spawn once.
>
> On the clientside, a single image can draw multiple elements with some
> ninja CSS stuff. ( background-position
On Thu, Sep 24, 2009 at 7:33 AM, Tisza Gergő wrote:
> It is easy enough to edit for power users, who make the large majority of
> edits;
Retention of existing users is not a problem. We don't have to worry
that a significant number of dedicated contributors will leave because
of a switch to WYS
Tisza Gergő wrote:
> Aryeh Gregor gmail.com> writes:
>> Wikitext is not easy to edit.
>
> It is easy enough to edit for power users, who make the large majority of
> edits;
>
> And then there is the ecosystem of bots, gadgets and other third-party tools
One more thing: wikitext diffs are more
2009/9/24 Aryeh Gregor :
> On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov wrote:
>> So it would be menu and icon-driven editing, where the hands should move
>> from keyboard to mouse and vice versa, like MS Word. Not very handy for
>> programmers and people who prefer to do most of tasks in com
On Thu, Sep 24, 2009 at 4:41 AM, Tim Starling wrote:
> * Removes a few RTTs for non-pipelining clients
Do you mean to imply that there's such a thing as a pipelining client
on the real web? (Okay, okay, Opera.) This concern seems like it
outweighs all the others put together pretty handily
On Thu, Sep 24, 2009 at 10:48 AM, dgerard wrote:
> Realistically, Tim has already stated we're not throwing out wikitext
> because of the huge body of text already in it.
Not in the foreseeable future, but maybe someday. We'd just need a
very careful and thorough migration plan.
> WYSIWYG editi
On Thu, Sep 24, 2009 at 7:27 AM, Aryeh Gregor
wrote:
> Last I heard, by the way, even now most actual *content* is added by
> occasional contributors. Power users may have more edits, but that
> doesn't mean they're the most important ones.
It may depend on your definition of "occasional con
Tei wrote:
> Possibly-OFF-TOPIC-here
>
>
> I see that ImageMagick can combine images in a single one.
>
> A single image mean a single hit to a Apache, so it only have to spawn once.
>
> On the clientside, a single image can draw multiple elements with some
> ninja CSS stuff. ( background-posit
Hi,
Just to clarify a few things:
- yes, it's important to distinguish between the editing of templates and
the editing of template calls. Most people understand that distinction, but
just to clarify, this project would allow for editing of template *calls*;
while template pages themselves would
> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
> Aryeh Gregor
> Sent: 24 September 2009 15:48
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards
> branchingMedia
* dgerard [Thu, 24 Sep 2009 15:48:16 +0100]:
> Realistically, Tim has already stated we're not throwing out wikitext
> because of the huge body of text already in it. WYSIWYG editing is
> getting there bit by bit - FCKeditor would be fine on a fresh wiki
> without the unspeakable atrocities invent
* Aryeh Gregor [Thu, 24 Sep 2009
09:57:27 -0400]:
> Programmers rank far, far below normal people when it comes to
> usability prioritization. Programmers can use WYSIWYG just as well as
> anyone else, even if it's not as powerful as they'd like. FWIW, on
> forums I go to where I can use either
Aryeh Gregor wrote:
> On Thu, Sep 24, 2009 at 4:41 AM, Tim Starling wrote:
>> * Removes a few RTTs for non-pipelining clients
>
> Do you mean to imply that there's such a thing as a pipelining client
> on the real web? (Okay, okay, Opera.) This concern seems like it
> outweighs all the oth
On 9/24/09 9:31 AM, Jared Williams wrote:
>>> * Automatically create CSS sprites?
>>>
>> That would be neat, but perhaps a bit tricky.
>>
> Just trying to think how it'd work.
>
> Given a CSS selector, and an image, should be able to construct a
> stylesheet which sets the background
On 9/23/09 5:02 PM, Brion Vibber wrote:
> ThomasV has fixed up some bad queries in ProofreadPage, and it should be
> ready to go again; the updated version has much more advanced index
> support and looks pretty spiffy. :)
ProofreadPage updates have been put live, and aren't killing servers
this
On 9/23/09 5:02 PM, Brion Vibber wrote:
> Roan's redone LU to store the message updates in serialized files
> instead of the database, which we can sync locally to web servers and
> should perform much better; I'll also do a more gradual test rollout so
> we can scale it back more gracefully if we
~some comments inline~
Tim Starling wrote:
[snip]
> I started off working on fixing the coding style and the most glaring
> errors from the JS2 branch, but I soon decided that I shouldn't be
> putting so much effort into that when a lot of the code would have to
> be deleted or rewritten from scr
On Thu, Sep 24, 2009 at 11:20 AM, rarohde wrote:
> It may depend on your definition of "occasional contributor" and
> "power user", but the way I tend to think about such distinctions
> would suggest your statement is false. I've never been able to do the
> analysis directly for enwiki, because i
On Thu, Sep 24, 2009 at 12:47 PM, Dmitriy Sintsov wrote:
> The only really complex part of wikitext are the templates - nested,
> sometimes really weird subst and so on.
Templates and refs are by far the worst offenders, for sticking tons
of content in the page that doesn't have any obvious relat
2009/9/24 Aryeh Gregor :
> On Thu, Sep 24, 2009 at 10:48 AM, dgerard wrote:
>> WYSIWYG editing is
>> getting there bit by bit - FCKeditor would be fine on a fresh wiki
>> without the unspeakable atrocities inventive geeks have perpetrated
>> upon wikitext on en:wp and should continue to get bette
2009/9/24 Dmitriy Sintsov :
> The only really complex part of wikitext are the templates - nested,
> sometimes really weird subst and so on. I remember reading "Advanced
> Templates" at meta and have the feeling I am reading something really
> cryptic - I am still not good at making complex templa
2009/9/24 Aryeh Gregor :
> Do these statistics take into account things like vandalism
> reversions? Also, how do they handle anonymous users -- are they
> summed up by edit count like anyone else? I distinctly remember
> seeing a study conclude that most of the actual content comes from
> users
On Thu, Sep 24, 2009 at 12:49 PM, Tim Starling wrote:
> It's not really as simple as that. The major browsers use concurrency
> as a substitute for pipelining. Instead of queueing up multiple
> requests in a single TCP connection and then waiting, they queue up
> multiple requests in multiple conn
On Thu, Sep 24, 2009 at 8:48 AM, dgerard wrote:
> 2009/9/24 Aryeh Gregor
>
> >:
> > On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov
> wrote:
>
> >> So it would be menu and icon-driven editing, where the hands should move
> >> from keyboard to mouse and vice versa, like MS Word. Not very handy
On Thu, Sep 24, 2009 at 4:03 PM, Brian wrote:
> This round the Usability Initiative got 800,000 dollars. That's a load of
> money. If the Foundation decides that it wants to fix the problem the
> correct way then it can. And it can start at any time! We just need to agree
> on a solution.
Only at
On 9/24/09 1:41 AM, Tim Starling wrote:
> Trevor Parscal wrote:
>
>> If you are really doing a JS2 rewrite/reorganization, would it be
>> possible for some of us (especially those of us who deal almost
>> exclusively with JavaScript these days) to get a chance to ask
>> questions/give feedback/
On Thu, Sep 24, 2009 at 2:22 PM, Aryeh Gregor
> wrote:
> On Thu, Sep 24, 2009 at 4:03 PM, Brian wrote:
> > This round the Usability Initiative got 800,000 dollars. That's a load of
> > money. If the Foundation decides that it wants to fix the problem the
> > correct way then it can. And it can s
On Thu, Sep 24, 2009 at 4:28 PM, Brian wrote:
> I definitely think it's a good idea to go after the low hanging fruit first,
> which it sounds like is what they are doing with this 800k. Fixing the core
> of the problem is definitely not low hanging fruit - it's hard work. On the
> other hand, the
> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
> Trevor Parscal
> Sent: 24 September 2009 19:38
> To: wikitech-l@lists.wikimedia.org
> Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards
> br
On Thu, Sep 24, 2009 at 10:44 PM, Peter Gervai wrote:
> Adding a gui layer to wikitext is always okay, as long as it's
> possible to get rid of, since majority of edits not coming from "new
> users", and losing flexibility for power users to get more newbies
> doesn't sound like a good deal to me.
On 9/24/09 1:40 PM, Jared Williams wrote:
>
>
>
>> -Original Message-
>> From: wikitech-l-boun...@lists.wikimedia.org
>> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
>> Trevor Parscal
>> Sent: 24 September 2009 19:38
>> To: wikitech-l@lists.wikimedia.org
>> Subject: Re:
On Thu, Sep 24, 2009 at 2:38 PM, Aryeh Gregor
> wrote:
> On Thu, Sep 24, 2009 at 4:28 PM, Brian wrote:
> > I definitely think it's a good idea to go after the low hanging fruit
> first,
> > which it sounds like is what they are doing with this 800k. Fixing the
> core
> > of the problem is defini
> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org
> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
> Trevor Parscal
> Sent: 24 September 2009 21:49
> To: wikitech-l@lists.wikimedia.org
> Subject: Re: [Wikitech-l] JS2 design (was Re: Working towards
> br
Brian wrote:
> This round the Usability Initiative got 800,000 dollars. That's a load of
> money. If the Foundation decides that it wants to fix the problem the
> correct way then it can. And it can start at any time! We just need to agree
> on a solution.
>
> We can't fix the problem by looking b
2009/9/24 Platonides :
> Brian wrote:
>> * wikitext parsing would be much faster if the language was well defined and
>> we could use flex/bison/etc...
> Have you read the archives?
> It has been tried. Several times.
> There's even a mailing list for that.
> Getting a formal definition of ~90% o
On Thu, Sep 24, 2009 at 12:50 PM, David Gerard wrote:
> 2009/9/24 Aryeh Gregor :
>
>> Do these statistics take into account things like vandalism
>> reversions? Also, how do they handle anonymous users -- are they
>> summed up by edit count like anyone else? I distinctly remember
>> seeing a stu
2009/9/24 Robert Rohde :
> I went into it expecting a result like that described in the blog
> post, and came out with the opposite conclusion.
> PS. A full write-up of this analysis has been on my to-do list for a while
> now.
If you could do it sooner rather than later, that would be of
treme
On 9/24/09 2:34 PM, Jared Williams wrote:
>
>
>
>> -Original Message-
>> From: wikitech-l-boun...@lists.wikimedia.org
>> [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
>> Trevor Parscal
>> Sent: 24 September 2009 21:49
>> To: wikitech-l@lists.wikimedia.org
>> Subject: Re:
I'm using Chrome 3.0.195.21, and have long found that some characters
in Wikipedia render as boxes. One example:
http://en.wikipedia.org/wiki/P_with_stroke renders as "
(minuscule: )..."
Now, I looked at http://en.wikipedia.org/wiki/Help:Special_characters
and the advice is not very useful or spec
On Thu, Sep 24, 2009 at 4:05 PM, Platonides wrote:
> Brian wrote:
> > This round the Usability Initiative got 800,000 dollars. That's a load of
> > money. If the Foundation decides that it wants to fix the problem the
> > correct way then it can. And it can start at any time! We just need to
> ag
On 9/24/09 12:23 PM, Brion Vibber wrote:
> Ok, the updated LocalisationUpdate is running on test.wikipedia.org and
> aa.wikipedia.org; have run one update but haven't set it up as a cron
> job yet.
>
> Will roll out progressively to more client wikis later while watching
> the CPU. :)
>
> Config de
On Thu, Sep 24, 2009 at 05:44, Peter Gervai wrote:
> On Thu, Sep 24, 2009 at 14:36, David Gerard wrote:
>
>> However, impenetrable wikitext is one of *the* greatest barriers to
>> new users on Wikimedia projects. And this impenetrability is not, in
>> any way whatsoever or by any twists of logic,
On Fri, Sep 25, 2009 at 8:05 AM, Platonides wrote:
> 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.
I wouldn't put it quite like that. Yes, the problem gets harder as you
get nearer the end - but it als
>> * The namespacing in Google's jsapi is very nice, with everything
>> being a member of a global "google" object. We would do well to
>> emulate it, but migrating all JS to such a scheme is beyond the scope
>> of the current project.
>>
>
> You somewhat contradict this approach by recommendi
Hi
Now I have constructed a local wiki.And I want to add the data which download
from the internet Wikipedia to the local wiki.I tried to read the source
code,but I coudln’t find the exact thing(Interface) that I want.
So,I want to ask some questions:
when click the save button after edit an
* Aryeh Gregor [Thu, 24 Sep 2009
15:40:46 -0400]:
> Templates and refs are by far the worst offenders, for sticking tons
> of content in the page that doesn't have any obvious relationship to
> the actual content. Getting rid of them would be a huge step forward.
> But stuff like '''bold''' and
On Fri, Sep 25, 2009 at 4:00 PM, Dmitriy Sintsov wrote:
> What's complex in '''bold''' and ==headings== ? Here when we've
It *looks* complex. That's pretty much most of the problem. Here's our
desired use case:
1) User views a page that is deficient in some way.
2) User decides to edit.
3) User
60 matches
Mail list logo
