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-lMay 2010

wikitech-l@lists.wikimedia.org
  • 90 participants
  • 62 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
User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25
Hi!from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites.Domas
19 61
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
Backups
by Eugene 07 Nov '10

07 Nov '10
Hi everyone,Are there any updates regarding Wikipedia's backup systems? I'vecreated a bug to track this athttps://bugzilla.wikimedia.org/show_bug.cgi?id=18255.Cheers,Eugene
4 5
0 0
Hi!I've read on the techblog that the new UI go live in April. I havesome questions:1) What version? Acai, babaco, citron?2) How/where could a wiki customize the special character insert menu,and the inserted strings? And the embed file (picture) button insertsthis: "[[Example.jpg]]", without any "File:" or "Image:"!3) The search and replace button is available in firefox, but does notappear at all in opera. Why?4) Currently the new navigable TOC does not work on FF/Opera at all(I've tried those).Not too early for live deployment?Regards,Akos Szabo (Glanthor Reviol)
21 45
0 0
implementing the Interlanguage extension
by Amir E. Aharoni 06 Aug '10

06 Aug '10
Sorry about bugging the list about it, but can anyone please explainthe reason for not enabling the Interlanguage extension?See bug 15607 -https://bugzilla.wikimedia.org/show_bug.cgi?id=15607I believe that enabling it will be very beneficial for many projectsand many people expressed their support of it. I am not saying thatthere are no reasons to not enable it; maybe there is a good reason,but i don't understand it. I also understand that there are many otherunsolved bugs, but this one seems to have a ready and rather simplesolution.I am only sending it to raise the problem. If you know the answer, youmay comment at the bug page.Thanks in advance.-- Amir Elisha Aharoniheb:http://haharoni.wordpress.com | eng:http://aharoni.wordpress.comcat:http://aprenent.wordpress.com | rus:http://amire80.livejournal.com"We're living in pieces, I want to live in peace." - T. Moore
6 8
0 0

05 Jun '10
Hello to all!I'm a French student and I am participating the Google Summer of Codethis year on Mediawiki!My mentor is Roan Kattouw (Catrope) and my subject is "Reasonablyefficient interwiki transclusion". You can see my application pagehere: [1].I have already discussed with my mentor and we have prepared togethera draft about my project: [2]. It sums up the current situation andincludes some proposals.It is now open for comments, so, could you please read it and let meknow about your remarks and suggestions, on this list and/or on thetalk page?Thanks in advance[1]http://www.mediawiki.org/wiki/User:Peter17/GSoc_2010[2]http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_t…--Peter Potrowlhttp://www.mediawiki.org/wiki/User:Peter17
16 40
0 0
a wysiwyg editor for wikipedia?
by William Le Ferrand 04 Jun '10

04 Jun '10
Dear all,I've started to develop a simple wysiwyg editor that could be useful towikipedia. Basically the editor gets the wiki code from wikipedai and buildsthe html on client side. Then you can edit the html code as you can imagineand when you are done another script converts the html back to wiki code.There is a simple demo here :http://www.corefarm.com:8080/wysiwyg?article=Open_innovation . You can tryother pages fromhttp://www.corefarm.com:8080/ (type the article name).It's far from being really usable now but do you think that such a toolwould be useful ? The global structure is ok, most of the buttons areworking (even if there are no special images to figure out what theyactually do); it's just a matter of filling the gaps and support all thewikipedia syntax.You comments are welcomed!All the best,William
14 22
0 0
Hi all,For those who don't know me, I'm one of the GSOC students this year.My mentor is ^demon, and my project is to enhance support for metadatain uploaded files. Similar to the recent thread on interwikitransclusions, I'd thought I'd ask for comments about what I proposeto do.Currently metadata is stored in img_metadata field of the image tableas a serialized php array. Well this works fine for the primary usecase - listing the metadata in a little box on the image descriptionpage, its not very flexible. Its impossible to do queries like get alist of images with some specific metadata property equal to somespecific value, or get a list of images ordered by what softwareedited them.So as part of my project I would like to move the metadata to its owntable. However I think the structure of the table will need to be alittle more complicated then just <page id>, <name>, <value> triples,since ideally it would be able to store XMP metadata, which cancontain nested structures. XMP metadata is pretty much the mostcomplex metadata format currently popular (for metadata stored insideimages anyways), and can store pretty much all other types ofmetadata. Its also the only format that can store multi-lingualcontent, which is a definite plus as those commons folks love theirlanguages. Thus I think it would be wise to make the table storeinformation in a manner that is rather close to the XMP data model.So basically my proposed metadata table looks like:*meta_id - primary key, auto-incrementing integer*meta_page - foreign key for page_id - what image is this for*meta_type - type of entry - simple value or some sort of compoundstructure. XMP supports ordered/unordered lists, associative arraytype structures, alternate array's (things like arrays listing thevalue of the property in different languages).*meta_schema - xmp uses different namespaces to prevent namecollisions. exif properties have their own namespace, IPTC propertieshave their own namespace, etc*meta_name - The name of the property*meta_value - the value of the property (or null for some compoundthings, see below)*meta_ref - a reference to a meta_id of a different row for nestedstructures, or null if not applicable (or 0 perhaps)*meta_qualifies - boolean to denote if this property is a qualifier(in XMP there are normal properties and qualifiers)(seehttp://www.mediawiki.org/wiki/User:Bawolff/metadata_table for alonger explanation of the table structure)Now, before everyone says eww nested structures in a db areinefficient and what not, I don't think its that bad (however I'm newto the whole scalability thing, so hopefully someone moreknowledgeable than me will confirm or deny that).The XMP specification specifically says that there is no artificiallimit on nesting depth, however in general practise its not nestedvery deeply. Furthermore in most cases the tree structure can besafely ignored. Consider:*Use-case 1 (primary usecase), displaying a metadata info box on animage page. Most of the time that'd be translating specific name andvalues into html table cells. The tree structure is totallyunnecessary. for example the exif property DateTimeOriginal can onlyappear once per image (also it can only appear at the root of the treestructure but thats beside the point). There is no need to reconstructthe tree, just look through all the props for the one you need. If thetree structure is important it can be reconstructed on the php side,and would typically be only the part of the tree that is relevant, notthe entire nested structure.*Use-case 2 (secondary usecase). Get list of images ordered by someproperty starting at foo. or get list of images where property bar =baz. In this case its a simple select. It does not matter where in thetree structure the property is.Thus, all the nestedness of XMP is preserved (So we could re-output itinto xmp form if we so desired), and there is no evil joining themetadata table with itself over and over again (or at all), which fromwhat i understand, self-joining to reconstruct nested structures iswhat makes them inefficient in databases.I also think this schema would be future proof because it can storepretty much all metadata we can think of. We can also extend it withcustom properties we make up that are guaranteed to not conflict withanything (The X in xmp is for extensible).As a side-note, based on my rather informal survey of commons (aka thecouple people who happened to be on #wikimedia-commons at that moment)another use-case people think would be cool and useful is metadataintersections, and metadata-category intersections. I'm not planningto do this as part of my project, as I believe that would haveperformance issues. However doing a metadata table like this doesleave the possibility open for people to do such intersection thingson the toolserver or in a DPL-like extension.I'd love to get some feedback on this. Is this a reasonable approachfor me to take on this.Thanks for reading.---bawolff
8 12
0 0
Results per page:
[8]ページ先頭
©2009-2025 Movatter.jp