Movatterモバイル変換

[0]ホーム
URL:

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview
List overview
Download

Wikitech-lMarch 2008

wikitech-l@lists.wikimedia.org
  • 97 participants
  • 94 discussions
Start a nNew thread
Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25
Until some weeks agohttp://dumps.wikimedia.org/backup-index.html usedto show 4 dumps in progress at the same time. That meant that newdatabase dumps normally was available within about 3 weeks for alldatabases except for enwiki and maybe dewiki where the dump process dueto size took longer time.However the 4 dumps processes at one time become 3 some weeks ago. Andafter massive failures at June 4, only one dump has been in progress atthe same time. So at the current speed it will take several months tocome thru all dumps.Is it possible to speed up the process again using several dumpprocesses at the same time?Thank you,Byrial
3 2
0 0
EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25
What's the status of the project to create a grammar for Wikitext in EBNF?There are two pages:http://meta.wikimedia.org/wiki/Wikitext_Metasyntaxhttp://www.mediawiki.org/wiki/Markup_specNothing seems to have happened since January this year. Also the comments onthe latter page seem to indicate a lack of clear goal: is this just a funproject, is it to improve the existing parser, or is it to facilititate anew parser? It's obviously a lot of work, so it needs to be of clearbenefit.Brion requested the grammar IIRC (and there's a comment to that effect athttp://bugzilla.wikimedia.org/show_bug.cgi?id=7), so I'm wondering what became of it.Is there still a goal of replacing the parser? Or is there some alternativeplan?Steve
26 217
0 0
MediaWiki to Latex Converter
by Hugo Vincent 18 Jun '12

18 Jun '12
Hi everyone,I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/) and I need to extra the content from it and convert it into LaTeX syntax for printed documentation. I have googled for a suitable OSS solution but nothing was apparent.I would prefer a script written in Python, but any recommendations would be very welcome.Do you know of anything suitable?Kind Regards,Hugo Vincent,Bluewater Systems.
6 13
0 0

13 Oct '09
I've been putting placeholder images on a lot of articles on en:wp.e.g. [[Image:Replace this image male.svg]], which goes to[[Wikipedia:Fromowner]], which asks people to upload an image if theyown one.I know it's inspired people to add free content images to articles inseveral cases. What I'm interested in is numbers. So what I'd need isa list of edits where one of the SVGs that redirects to[[Wikipedia:Fromowner]] is replaced with an image. (Checking which ofthose are actually free images can come next.)Is there a tolerably easy way to get this info from a dump? AnyWikipedia statistics fans who think this'd be easy?(If the placeholders do work, then it'd also be useful convincing somewikiprojects to encourage the things. Not that there's ownership ofarticles on en:wp, of *course* ...)- d.
7 11
0 0
Case insensitive links (not just titles).
by subscribe＠divog.com.ru 24 Jun '08

24 Jun '08
Hi Sorry for my English :) What I need is case insensitive titles. My solution for the problem was tochange collation in mysql from <unf8_bin> to <utf8_general_ci> in table<page>, for field <page_title>. But bigger problem with links persists. In my case, if there is an article<Frank Dreben>, link [[Frank Dreben]] is treated like a link to an existentarticle (GoodLink), but link [[frank dreben]] is treated like a link to anon-existent article, so, this link opens editing of existent article <FrankDreben>. What can be fixed for that link [[frank dreben]] to be treated likea GoodLink? I've spent some time in Parser.php, LinkCache.php, Title.php, Linker.php,LinkBatch.php but found nothing useful. The last thing I tried was to dostrtoupper on title every time array of link cache is filled, inLinkCache.php. I also tried to do strtoupper on title every time data isfetched from the array.I've tried to make titles in cache be case insensitive, but it didn't workout, not sure why - it seems like when links are constructed (parser, title,linker, etc) only LinkCache methods are used. Could anybody point a direction to dig in? :)
7 36
0 0
Wysiwyg
by Cormac Lawler 23 May '08

23 May '08
Hi,I know a lot of people would love wysiwyg editing functionality, I know alot of people on this list are working on such a thing, and I know that aproblem seems to be the "grammar" involved. I heard on the grapevine that,on this basis, it was "at least a year away". I don't want to know thespecifics of what that grammar is, or what its problems are. :-) But whatI'd like to know is:* Would this issue be solved quicker by having a few funded developersworking on it? (If so, how many wo/man hours would be needed - what size ofa funding bid would be needed?)* What does the fckeditor in existence *not* do yet? <http://mediawiki.fckeditor.net> (If the answer is: "too much - it only doesa tiny handful of things compared to what we need" - well then, that answersmy question. :-))If you haven't already surmised, this question is from a technical dunce -answers at that level would be greatly appreciated. :-)Cheers,Cormac
5 4
0 0
Interface embarrassment rant
by Magnus Manske 24 Apr '08

24 Apr '08
<rant>I'm currently working on the Scott Forseman image donation, cuttinglarge scanned images into smaller, manually optimized ones.The category containing the unprocessed images ishttp://commons.wikimedia.org/wiki/Category:ScottForesman-rawIt's shameful. Honestly. Look at it. We're the world's #9 top website, and this is the best we can do?Yes, I know that the images are large, both in dimensions(~5000x5000px) and size (5-15MB each).Yes, I know that ImageMagick has problems with such images.But honestly, is there no open source software that can generate athumbnail from a 15MB PNG without nuking our servers?In case it's not possible (which I doubt, since I can generatethumbnails with ImageMagick from these on my laptop, one at a time;maybe a slow-running thumbnail generator, at least for "usual" sizes,on a dedicated server?), it's no use cluttering the entire page withbroken thumbnails.Where's the option for a list view? You know, a table with linkedtitle, size, uploader, date, no thumbnails? They're files, so whydon't we use things that have proven useful in a file system?And then, of course:"There are 200 files in this category."That's two lines below the "(next 200)" link. At that point, we knowthere are more than 200 images, but we forget about that two linesfurther down?Yes, I know that some categories are huge, and that it would take toolong to get the exact number.But, would the exact number for large categories be useful? 500.000 or500.001 entries, who cares? How many categories are that large anyway?200 or 582 entries, now /that/ people might care about.Why not at least try to get a number, set a limit to, say, 5001, and* give the exact number if it's less that 5001 entries* say "over 5000 entries" if it returns 5001Yes, everyone's busy.Yes, there are more pressing issues (SUL, stable versions, you name it).Yes, MediaWiki wasn't developed as a media repository (tell me about it;-)Yes, "sofixit" myself.Still, I ask: is this the best we can do?Magnus</rant>
15 56
0 0
The most recent enwiki dump seems corrupt (CRC failure when bunzipping).Another person (Nessus) has also noticed this, so it's not just me:http://meta.wikimedia.org/wiki/Talk:Data_dumps#Broken_image_.28enwiki-20080…Steps to reproduce:lsb32@cmt:~/enwiki> md5sum enwiki-20080103-pages-meta-current.xml.bz29aa19d3a871071f4895431f19d674650 enwiki-20080103-pages-meta-current.xml.bz2lsb32@cmt:~/enwiki> bzip2 -tvvenwiki-20080103-pages-meta-current.xml.bz2 &> bunzip.loglsb32@cmt:~/enwiki> tail bunzip.log [3490: huff+mtf rt+rld] [3491: huff+mtf rt+rld] [3492: huff+mtf rt+rld] [3493: huff+mtf rt+rld] [3494: huff+mtf rt+rld] [3495: huff+mtf data integrity (CRC) error in dataYou can use the `bzip2recover' program to attempt to recoverdata from undamaged sections of corrupted files.lsb32@cmt:~/enwiki> bzip2 -Vbzip2, a block-sorting file compressor. Version 1.0.3, 15-Feb-2005. Copyright (C) 1996-2005 by Julian Seward. This program is free software; you can redistribute it and/or modify it under the terms set out in the LICENSE file, which is included in the bzip2-1.0 source distribution. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE file for more details.bzip2: I won't write compressed data to a terminal.bzip2: For help, type: `bzip2 --help'.lsb32@cmt:~/enwiki>
4 6
0 0
JS Libraries in MediaWiki
by DanTMan 16 Apr '08

16 Apr '08
Erm... never, EVER! try to write a long e-mail on a Wii... Especially when occasionally your Wi-Fi disconnects which ends up killing everything you've written.Well onto the topic...I've notice that the number of extensions using JS Libraries has increased recently. Notably Semantic MediaWiki/Semantic Forms, and SocialProfile. Additionally I was contracted to create a new mp3 playing extension because all the current ones break the lines (The requester wants to be able to let the music play inline, basically beside a normal link to an audio file, instead of needing a plugin or something on their computer, or a big player that takes up unneeded space)... So I found the mp3inline <http://pjoe.net/software/mp3inline/> Wordpress plugin, and intend to adapt some of it into a MediaWiki extension which will automatically let audio links be playable inline with an icon located cleanly beside the link. Of course, the note on this topic is that the player uses Scriptaculous which is another JS Library which would be put into MW.Various extensions use different methods of including the libraries they need. Mostly just requiring the user to find a way to put it in. However SocialProfile includes a YUI extension which can be used. This extension however is basically just a short bit that includes a single script which is basically a minified part of the basic required YUI code, and an unminified version of the animation package (Why they used the minified version for one half, and the full version of another part is beyond me though)...The biggest issue with any of these that I see... Is load time. For all of them you need to add a bunch of script tags to the page for them to work, and suddenly you drastically increase the number of HTTP calls for stuff on your site.Since things are growing, I was thinking it would be a good idea to add some stuff to core to allow extensions to add use of JS libraries in an intuitive way. I started an allinone.php extension awhile ago (inspired by Wikia's allinone.js idea) and was thinking I should probably rewrite it and make something good for core.The idea is to have a single script in the page which contains all of the needed JS Libraries... And even wikibits.js inside it... All of them minified to compact space... Of course, if you need to debug any errors or anything, simply reload the page with &allinone=0 and the system automatically includes the separate non-minified files in individual script tags for debugging. Perhaps even a no-allinone preference for those doing heavy debugging in areas where they have a post request they can't add &allinone=0 to.Additionally, the system would have a understanding of the structure of a js library. Basically, a sort of definition module would be created for each library that people may use (YUI, jQuery, Scriptaculous, Prototype, etc...) which would outline things like the different parts of the system (Core file, individual parts of the system like ui or other things only needed sometimes, separation of full/minified files (perhaps a notion of debug like what YUI has), and files like YUI's utilities.js or yahoo-dom-event.js which are minified versions of a grouping of various parts of the library.)And using calls like, say... Making the thing handling this called "JSLibs" just for this example... JSLibs::addUse( 'YUI', 'animation' ); which would note that YUI's animation bit is required for use in the page. And so it'll automatically know that the 'yahoo' bit is also needed, additionally if various other things like the dom, event, etc... bits are needed it'll automatically use one of the combined files instead of individual ones.Of course, there is a little bit of optimization by use that things using the libs need to do...Primarily this is because some things are needed at some times, and not at others... But if you don't define good times that it should be included, then the number of varying types of allinone groups you have increases and you end up with more stuff for the browser to cache and more requests to the server.So basically:* Skins... For the JS Libraries that they require, they should include the libraries all the time when inside of that skin. (There'll be code to let Skins define what they need inside of the definition of where to put the stuff)* Site scripts... When JS Libraries are wanted for site scripting, the stuff should be included using calls inside of LocalSettings.php and included all the time.* Extensions... It depends on what kind of extension...** For low use things inside articles, like perhaps a TagCloud which is likely only to be used on a few major pages, this should be only included when needed (ie: The thing needing it is parsed into existence)** For special page stuff, and things meant for only edit pages and the like the libraries should always be included while on these pages, but not in general while reading articles.** For high use things, like SMW's attributes, factboxes, and such... The libraries should be included 100% of the time... Of course, if you really want you can put in some exclusions for when on special pages... But these are used a high amount of times, and can add up the number of variations easily.If you don't understand what I'm meaning... It occurs when multiple extensions of different types are used...For example... Say we had a low use tag cloud, and something like SMW which included dynamic stuff every time an attribute was used...If the tag cloud loaded only when needed, and SMW included only when an attribute was used... then we'd have the variations:* One for when tag cloud, and SMW attributes are used (main pages mostly)* One for when tag cloud isn't used, but SMW attributes are used (most article pages)* One for when tag cloud is used, but SMW attributes are not (extremely rare case)* And one for when the tag cloud isn't used, and SMW attribues are not (another rare case)Those last two shouldn't exist... They only exist because one extension didn't define when stuff should be included right.If the example SMW had loaded it's libraries 100% of the time when on articles because of the high use of it... Then there would only be two variations, one for with tag cloud, and one for when it's not...Another issue, is minification... Not everything comes with a minified counterpart... I was hoping to make this something which could be done automatically. However, I found out that most of the minification programs that seam to be good, run in other languages like Java, rather than having PHP ports. So perhaps a toolserver service would be nice, one allowing extension authors to submit a page of code in a form to the toolserver, and have it return them a minified version using the best program for the job, that way people developing scripts and stuff for use can distribute the extension with pre-minified code, rather than requiring the people using the extension to download something to minify the code on their own.^_^ And yes, of course we'd have a minified version of wikibits.js... We include it 100% of the time, why waste bytes on the comments and whitespace? Especially when using a non-minified/minified split allows us to put nice literate documentation inside of the code, while still making end use of something extremely compact.-- ~Daniel Friesen(Dantman) of:-The Gaiapedia (http://gaia.wikia.com)-Wikia ACG onWikia.com (http://wikia.com/wiki/Wikia_ACG)-andWiki-Tools.com (http://wiki-tools.com)
4 8
0 0
Interwiki updates/ bugzilla
by Andrew Cates 11 Apr '08

11 Apr '08
Just a reminder that its six weeks and ten changes since the lastinterwiki update.Does this bughttps://bugzilla.wikimedia.org/show_bug.cgi?id=12763about the updates need closing since there was an update 10 Feb, orshould we keep until the process is an automated monthly task say?Keep up the good workBozMo
1 1
0 0
Results per page:
[8]ページ先頭
©2009-2025 Movatter.jp