headers
Michael Dale | 1 Apr 03:13
Picon

add media wizard in testing / update

The add media Wizard is in testing see blog post:
http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wikimediaorg/

If no one objects (or has any blocker bugs that I have missed) I will 
add the gadget option for firefogg / add media wizard to commons 
shortly. (for wider testing) We could also add the basic commons search 
as a gadget for wikipedia proper. (making commons image inserts much easier)
more about add_media_wizard: 
http://www.mediawiki.org/wiki/Extension:Add_Media_Wizard

The searching remote repository and in-line upload and template  via url 
component that is working on test.wikimedia.org is not as easy to push 
out. The implementation on  test.wikimedia.org is limited to files that 
it can copy in less than 30 seconds (php time out ) and is parsing html 
page output to determine errors.  To move the add media wizard searching 
and insert into production we will need to deploy the new-upload branch. 
I will be targeting fixes to upload bugs 18200, 18201, 18202 to the 
new-upload branch.

Looking beyond English language gadgets ...  Localization is dependent 
on the javascript script server which I will create a patch for core 
shortly.
more about js server:  http://www.mediawiki.org/wiki/Extension:ScriptLoader

peace,
--michael
Permalink | Reply | 0 comments |
headers
Ed Summers | 1 Apr 06:07
Picon
Favicon
Gravatar

Re: Providing simpler dump format (raw, SQL or CSV)?

On Tue, Mar 31, 2009 at 9:57 AM, howard chen <howachen <at> gmail.com> wrote:
> Given that the current dump process is having problem, why not provide
> a simple fix such as providing raw table format , SQL files or even
> CSV files?

Please pardon this newbie question: is there a succinct explanation of
what the problem is with the current Wikipedia dump process?

//Ed
Permalink | Reply | 3 comments |
headers
Aryeh Gregor | 1 Apr 15:28
Picon

Re: Providing simpler dump format (raw, SQL or CSV)?

On Wed, Apr 1, 2009 at 12:07 AM, Ed Summers <ehs <at> pobox.com> wrote:
> Please pardon this newbie question: is there a succinct explanation of
> what the problem is with the current Wikipedia dump process?

"needs a rewrite"?
Permalink | Reply | 1 comment |
headers
Michael Dale | 1 Apr 17:21
Picon

Re: add media wizard in testing / update

as some have pointed out its test.wikipedia.org ( not test.wikimedia.org )

Michael Dale wrote:
> The add media Wizard is in testing see blog post:
> http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wikimediaorg/
>
> If no one objects (or has any blocker bugs that I have missed) I will 
> add the gadget option for firefogg / add media wizard to commons 
> shortly. (for wider testing) We could also add the basic commons search 
> as a gadget for wikipedia proper. (making commons image inserts much easier)
> more about add_media_wizard: 
> http://www.mediawiki.org/wiki/Extension:Add_Media_Wizard
>
> The searching remote repository and in-line upload and template  via url 
> component that is working on test.wikimedia.org is not as easy to push 
> out. The implementation on  test.wikimedia.org is limited to files that 
> it can copy in less than 30 seconds (php time out ) and is parsing html 
> page output to determine errors.  To move the add media wizard searching 
> and insert into production we will need to deploy the new-upload branch. 
> I will be targeting fixes to upload bugs 18200, 18201, 18202 to the 
> new-upload branch.
>
> Looking beyond English language gadgets ...  Localization is dependent 
> on the javascript script server which I will create a patch for core 
> shortly.
> more about js server:  http://www.mediawiki.org/wiki/Extension:ScriptLoader
>
> peace,
> --michael
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yaron Koren | 1 Apr 17:52
Picon

Splitting up EditPage::showEditForm()

Hi,

The method showEditForm(), in the class EditPage, takes care of displaying
nearly the entire edit page. I would like to move the last section of this
method, which handles displaying the bottom of the edit page (everything
below the edit box) into its own method, perhaps called showFooter(). (This
basically corresponds to lines 1506 to 1566 of the current EditPage.php.)
showEditForm() would then call that new method. The reason for this move is
so that the extension Semantic Forms can subclass EditPage and override the
new method. But you could also make the case that it would improve
readability, modularity, whatever else. Any thoughts/objections?

-Yaron
Permalink | Reply | 1 comment |
headers
John Doe | 1 Apr 21:17
Picon

Re: Providing simpler dump format (raw, SQL or CSV)?

>
> what the problem is with the current Wikipedia dump process?
>
its choking with almost 300 million revisions.
it wasnt designed for a wiki this size and needed re-written two years ago

On Wed, Apr 1, 2009 at 9:28 AM, Aryeh Gregor
<Simetrical+wikilist <at> gmail.com<Simetrical%2Bwikilist <at> gmail.com>
> wrote:

> On Wed, Apr 1, 2009 at 12:07 AM, Ed Summers <ehs <at> pobox.com> wrote:
> > Please pardon this newbie question: is there a succinct explanation of
> > what the problem is with the current Wikipedia dump process?
>
> "needs a rewrite"?
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l <at> lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Permalink | Reply | 0 comments |
headers
Roan Kattouw | 1 Apr 23:52
Picon

Re: Splitting up EditPage::showEditForm()

2009/4/1 Yaron Koren <yaron57 <at> gmail.com>:
> Hi,
>
> The method showEditForm(), in the class EditPage, takes care of displaying
> nearly the entire edit page. I would like to move the last section of this
> method, which handles displaying the bottom of the edit page (everything
> below the edit box) into its own method, perhaps called showFooter(). (This
> basically corresponds to lines 1506 to 1566 of the current EditPage.php.)
> showEditForm() would then call that new method. The reason for this move is
> so that the extension Semantic Forms can subclass EditPage and override the
> new method. But you could also make the case that it would improve
> readability, modularity, whatever else. Any thoughts/objections?
>
I suggest you go ahead and do it: splitting out a piece of code into
its own function is not a big deal, provided your choices of what to
split out and what not to are somewhat sane.

Roan Kattouw (Catrope)
Permalink | Reply | 0 comments |
headers
jidanni | 2 Apr 23:19
Favicon
Gravatar

all those sess* files in /tmp

Like yo, do you fellas see what I do on your machines?
$ find /tmp -name sess\* 2>&-|wc -l
95853
$ find /tmp -name sess\* ! -empty 2>&-|wc -l
42637
$ find /tmp -name sess\* ! -empty 2>&-|xargs more 2>&-|less
/tmp/sess_d4espd7ur01k7rq75f83ff7t45
::::::::::::::
wsUserID|i:3;wsUserName|s:4:"Jini";wsToken|s:32:"...
/tmp/sess_rqc4ufi3ev1g8on3novneb9dc7
::::::::::::::
wsUserID|i:2;wsUserName|s:9:"WikiSysop";wsToken|s:32:"...;wsEditToken|s:32:"-...

Any better way than "leaving all those candy bar wrappers on the floor"?
Permalink | Reply | 4 comments |
headers
Platonides | 2 Apr 23:48
Picon

Re: all those sess* files in /tmp

jidanni <at> jidanni.org wrote:
> Like yo, do you fellas see what I do on your machines?
> $ find /tmp -name sess\* 2>&-|wc -l
> 95853
> $ find /tmp -name sess\* ! -empty 2>&-|wc -l
> 42637
> $ find /tmp -name sess\* ! -empty 2>&-|xargs more 2>&-|less
> /tmp/sess_d4espd7ur01k7rq75f83ff7t45
> ::::::::::::::
> wsUserID|i:3;wsUserName|s:4:"Jini";wsToken|s:32:"...
> /tmp/sess_rqc4ufi3ev1g8on3novneb9dc7
> ::::::::::::::
> wsUserID|i:2;wsUserName|s:9:"WikiSysop";wsToken|s:32:"...;wsEditToken|s:32:"-...
> 
> Any better way than "leaving all those candy bar wrappers on the floor"?

Configure your php to use another folder, store the sessions in
memcached....
Permalink | Reply | 0 comments |
headers
Aryeh Gregor | 3 Apr 00:17
Picon

Re: A proposal to simplify and improve footnote markup in Wikipedia

On Thu, Apr 2, 2009 at 5:58 PM, Platonides <Platonides <at> gmail.com> wrote:
> We have done other big changes in the past. Almost all
> creations/renamings of mediawiki messages need local community action!

The real problem is user CSS/JS, I suspect.  People tend to copy-paste
that, and changes to document structure can break a lot of it without
any easy way to gauge the extent of the problem or fix it.

(For those more familiar with CSS/JS than with MediaWiki, I'm
referring to user subpages here, e.g.,
http://en.wikipedia.org/wiki/User:Simetrical/monobook.js.  I'm not
referring to stuff people have in their browsers, which is of course
impossible to track or fix even in principle.)

> There's some code adding parameters to the wikilinks, but I find them
> ugly. I'd prefer compressing spans surrounding anchor elements into the a.
> Ie. <span foo="bar">[[baz]]</span> to produce <a href="baz"
> foo="bar">baz</a>

Those two constructs are different.  They really are not the same and
should not be treated as such.  Treating them the same sounds like a
really bad idea to me.
Permalink | Reply | 3 comments |

Gmane