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-lSeptember 2011

wikitech-l@lists.wikimedia.org
  • 111 participants
  • 132 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
Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24
Hello,I have been a WP editor since 2006. I hope you can help me. For some reasonI no longer have Section Heading titles showing in the Articles. This istrue of all Headings including the one that carries the Article subject'sname. When there is a Table of Contents, it appears fine and, when I clickon a particular Section, it goes to that Section, but all that is there is astraight line separating the Sections. There is also no button to edit aSection. If I edit the page and remove the "== ==" markers from the SectionTitles, the Title then shows up, but not as a Section Heading. Also, I don'thave any Date separators on my Want List. This started 2 days ago. Anythoughts?Thanks,Marc Riddell[[User:Michael David]]
10 11
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
About to commit improved DB2 database support
by Leons Petrazickis 21 Dec '11

21 Dec '11
I've been informally mentoring André, Tiago, Diego, and César. Theyare four students at Minho University who are currently working on aproject to improve DB2 database support in MediaWiki.So far, they've:- Fixed several outstanding issues with DB2 support involvingcharacter encoding, Windows vs Linux, etc- Added DB2 support to the new MediaWiki 1.17 Installer and Updater- Put in the appropriate Updater sql patches to reflect databaseschema changes since 1.14MediaWiki already had some DB2 support, but it's been broken since1.15 and never complete. As a result of their work, it's now possibleto successfully install MediaWiki on DB2 out of the box and to use thecore wiki features.I'll shortly commit their first patch using my SVN account (leonsp).I've taken some care to look over the code and make sure it abides bythe MediaWiki code guidelines.Regards,Leons Petrazickishttp://lpetr.org/blog/
7 9
0 0

28 Nov '11
Bug 24207 requests switching the math rendering preference default from itscurrent setting (which usually produces a nice PNG and occasionally producessome kinda ugly HTML) to the "always render PNG" setting.I'd actually propose dropping the rendering options entirely...* "HTML if simple" and "if possible" produce *horrible* ugly output thatnobody likes, so people use hacks to force PNG rendering. Why not justrender to PNG?* "MathML" mode is even *MORE* limited than "HTML if simple", making itentirely useless.* nobody even knows what "Recommended for modern browsers" means, but itseems to be somewhere in that "occasionally crappy HTML, usually PNG"continuum.So we're left with only two sane choices:* Always render PNG* Leave it as TeX (for text browsers)Text browsers will show the alt text on the images, which is... the TeXcode. So even this isn't actually needed for its stated purpose. (HiJidanni! :) lynx should show the tex source when using the PNG mode.)It's conceivable that a few folks really honestly prefer to see the latexsource in their graphical browsers (should at least do a quick stat check tosee if anybody uses it on purpose), but I wouldn't mind removing thateither.Fancier rendering like MathJax etc should be considered as a separate thing(and implemented a bit differently to avoid parser cache fragmentation!), sodon't let future mode concerns worry y'all. Any thoughts on whether thismakes sense to do for 1.18 or 1.19?https://bugzilla.wikimedia.org/show_bug.cgi?id=24207#c9-- brion
9 12
0 0

28 Nov '11
Hi!I am starting this thread because Brion's revision r94289 revertedr94289 [0] stating "core schema change with no discussion" [1].Bugs 21860 [2] and 25312 [3] advocate for the inclusion of a hashcolumn (either md5 or sha1) in the revision table. The primary usecase of this column will be to assist detecting reverts. I don't thinkthat data integrity is the primary reason for adding this column. Thehuge advantage of having such a column is that it will not be longernecessary to analyze full dumps to detect reverts, instead you canlook for reverts in the stub dump file by looking for the same hashwithin a single page. The fact that there is a theoretical chance of acollision is not very important IMHO, it would just mean that in veryrare cases in our research we would flag an edit being reverted whileit's not. The two bug reports contain quite long discussions and thisfeature has also been discussed internally quite extensively but oddlyenough it hasn't happened yet on the mailinglist.So let's have a discussion![0]http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94289[1]http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94541[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=21860[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=25312Best,Diederik
19 28
0 0
page view stats redux
by Ariel T. Glenn 16 Nov '11

16 Nov '11
I think we finally have a complete copy from December 2007 throughAugust 2011 of the pageview stats scrounged from various sources, nowavailable on our dumps server. Seehttp://dumps.wikimedia.org/other/pagecounts-raw/Ariel
9 16
0 0
Git migration planning
by Rob Lanphier 25 Oct '11

25 Oct '11
Hi everyone,For a long time, we've been talking about migrating from Subversion toGit. It's time to start getting more serious about it.First: the need to do this. There is pretty broad acceptance that weshould move to a distributed version control system (DVCS). Ourcurrent Subversion-based version control system has served us well,but we're in need of a more suitable version control system for ourdevelopment effort. Our community is very distributed, with manyparallel efforts and needs to integrate many different featureefforts. While we've developed lots of coping mechanisms, we surecould use a system that's well suited to more fluid branching andmerging.There has been resistance to this in the past, and there still may besome resistance. However, I think we've worn everyone down. :)Next: the selection of Git over other DVCSs. Over the past couple ofyears, other systems have been mentioned (Bzr, Hg), but there hasn'tbeen any evidence (at least on this mailing list) for anything otherthan mild support for the alternatives. As you might have seen, ourOps folks have already moved to Git[1], and while they're right in themiddle of the tough part of the learning curve, they seem to beadjusting just fine. The complaints seem to be of the "I really needto get used to that" variety rather than the "why are we doing thisagain?" variety. So, given the momentum that Git has, the amplediscussion we've had on the subject, and the fact that Ops is alreadyplanning to support Git, this seems to be a settled question.So now, the questions shift from "if?" to "when?" and "how?".When? After some amount of arm twisting by Erik and Brion (*hugz*),I've agreed to float a plan that has us making the migration by theend of the year. This is completely contingent on our ability to get1.19 deployed in a rapid fashion (which, if we can get through thecode review queue at our current rate, could be done in November).Until we have a more fleshed out plan, though, "end of the year"purely a guess, and subject to change (partly based on any ensuingconversation after this mail). However, assuming we can clear thetechnical hurdles, there's not any procedural issues I can see gettingin the way of a rapid transition.How? Lots of unsorted pieces. There are still decisions we need to make:* Code review tool: barring unforeseen complications, we're planningto use Gerrit. We need to make sure it'll be a suitable replacementfor our existing tool* How do we break up the repository? One big repo? Extensions eachget their own? We need to sort all of that out.A draft plan is available here:http://www.mediawiki.org/wiki/Git_conversionRob[1] ...or so I've read on Slashdot, so it must be true:http://hardware.slashdot.org/story/11/09/21/0531246/wikimedia-foundation-re…
18 26
0 0
Results per page:
[8]ページ先頭
©2009-2025 Movatter.jp