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 2006

wikitech-l@lists.wikimedia.org
  • 99 participants
  • 139 discussions
Start a nNew thread
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
10k
by Domas Mituzas 01 Dec '07

01 Dec '07
Hi,today we came over 10k HTTP requests per second (even with inter-squidtraffic eliminated). Especially thanks to Mark and Tim, who've beenimproving our caching, as well as doing lots of other work, andachieved incredible results (while I was slacking). Really, thanks!Domas
16 21
0 0
MediaWiki 1.6.4 released
by Brion Vibber 29 Jun '06

29 Jun '06
-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1MediaWiki 1.6.4 is a maintenance bug fix release, which rolls up some fixes toadditional minor problems and localization updates to the Spring 2006 quarterlysnapshot.* Further improvements to Hebrew localisation* (bug 5544) Fix redirect arrow in Special:Listredirects for right-to-left languages* Replace "doubleredirectsarrow" with a content language check that picks the appropriate arrow* Remove live debugging hack which caused errors with certain database names* (bug 5510) Warning produced when using {{SUBPAGENAME}} in some namespaces* (bug 5548) Improvements to Indonesian localisation [patch: Ivan Lanin]* (bug 5403) Fix Special:Newpages RSS/Atom feeds* (bug 3359) Add hooks on completion of file upload* (bug 5184) CSS misapplied to elements in Special:Allmessages due to conflicting anchor identifiers* (bug 5519) Allow sidebar cache to be disabled; disable it by default.* Add $wgReservedUsernames configuration directive to block account creation/use* (bug 5576) Remove debugging hack in session check* (bug 5181) Update "nogomatch" for Slovak* (bug 5594) Id translation up to '# Login and logout pages' section* (bug 5536) Use content language for editing help link* Minor improvements to English language files* Improvements to German localisation files* (bug 5628) Translations for MessagesHr.php* (bug 5595, 5644) Localisation for Bosnian language (bs)* (bug 5592) Actions are logged with the default language for the wiki, not the language of the user performing the operation.* (bug 5646) Compare for identical types in wfElement()* Fix for concurrency problem in job queue (image description page invalidation)* (bug 5497) regeression in HTML normalization in 1.6 (unclosed <li>,<dd>,<dt>)* (bug 5709) Allow customisation of separator for categories* (bug 4834) Fix XHTML output when using $wgMaxTocLevel* Improvements to update scripts; print out the version, check for superuser credentials before attempting a connection, and produce a friendlier error if the connection fails* (bug 5005): Fix XHTML <gallery> output.* (bug 5315) "Expires: -1" HTTP header made strictly valid (using 1970 date).* (bug 4825): note in DefaultSettings.php about 'profiling' table creation* Remove unneeded extra whitespace at top of Special:Categories* Rewrite reassignEdits script to be more efficient; support optional updates to recent changes table; add reporting and silent modes* Updated initStats maintenance script* (bug 5723) Don't count pages linked to from the MediaWiki namespace as "wanted"* (bug 5789) Treat "loginreqpagetext" as wikitext* (bug 5796) We require MySQL >=4.0.14Full release notes:http://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_6_4/phase3/RELEASE-NOTEShttp://svn.wikimedia.org/viewvc/mediawiki/tags/REL1_6_4/phase3/HISTORYDownload:http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.6.4.tar.gzMD5 checksum:3afc13074e29db9083fb73435e5e7371 mediawiki-1.6.4.tar.gzBefore asking for help, try the FAQ:http://www.mediawiki.org/wiki/FAQLow-traffic release announcements mailing list:(Please subscribe to receive announcements of security updates.)http://mail.wikimedia.org/mailman/listinfo/mediawiki-announceWiki admin help mailing list:http://mail.wikimedia.org/mailman/listinfo/mediawiki-lBug report system:http://bugzilla.wikimedia.org/Play "stump the developers" live on IRC:#mediawiki onirc.freenode.net- -- brion vibber (brion @pobox.com)-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.2.4 (Darwin)Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.orgiD8DBQFEV8sJwRnhpk1wk44RAkmoAKC6egTg4YhnXbPSn9BhbjiSC3a8OgCgsL1TSwVYtN4ftr3BBgBUsQWlgXw==HNzm-----END PGP SIGNATURE-----
3 3
0 0
207.142.131.221 listed in bl.spamcop.net
by Walter Vermeir 23 Jun '06

23 Jun '06
I have got a bounce because of this when send a reply to a OTRS-ticket.http://www.spamcop.net/w3m?action=checkblock&ip=207.142.131.221Can be seen what can be done about this?[[meta:user:Walter]]
6 8
0 0
Categories on nap.wikipedia.org don't work
by Sabine Cretella 20 Jun '06

20 Jun '06
Hi, we have a strange behaviour on the nap wikipedia. Strange enough the categories don't work well - the first one works - the others not ... hmmmhttp://nap.wikipedia.org/wiki/AcernoThe categories are inserted like this:[[category:giugrafia]][[category:Comune d<nowiki>''</nowiki>a Campania]][[category:Comune d<nowiki>''</nowiki>a pruvincia 'e Salierno]]now we tried the following:changed the category to Categoria, Category, categoriatook out the nowiki-tagThe only thing that works is take out the '' + the nowiki tag - so we get a category, but the resulting spelling is then plain wrong. It worked well up to the last version of the Mediawiki software ... so something must have been changed there.One thing I just tried out: also wiki-links do not work anymore - this means we cannot create correct pages anymore since <nowiki> does not seem to be allowed within a wiki link. This means problems with nap.wikipedia, but not only: also wiktionary will have (maybe already has) problems with this (we have approx. 3000 Neapolitan words (if I am right) in the Italian wiktionary - some of these probably use the '')Could someone please look into this?Thank you!Best, SabineChiacchiera con i tuoi amici in tempo reale!http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
16 53
0 0
single signon status?
by William Allen Simpson 11 Jun '06

11 Jun '06
I've searched the archives for the past several months, and cannot findthe status of this project, other than a busy fellow saying that it wasthe top priority in February. Anybody know?
5 6
0 0
title case mapping and Wiktionary links
by Steve Summit 04 Jun '06

04 Jun '06
Several of us on the English Wiktionary are trying to resolve an issueand we could use some advice.(This is my frist post to this list, so apologies if I restate theobvious.)What's the best way to rig it up so that when you interlink to [[Foo]]on a caseful Wiki project, where "Foo" does not exist but "foo" does,to give the user a convenient shortcut to [[foo]]?Background: unlike most Mediawiki projects, the English Wiktionaryhonors case in the first character of article titles . (That is, Iassume it has $wgCapitalLinks set to false.) This can cause problemswith links to Wiktionary from other Mediawiki projects, and from theoutside world (such as Wiktionary mirrors), since those incoming linksare often to the capitalized version of a word, on the assumption thatWiktionary works like Wikipedia. (As, in fact, it once did.)Even since it switched over to casefulness, Wiktionary has evidentlybeen trying to "solve" this problem by having an explicit, capitalizedredirect in place for every lower-case entry. But that's clearly a hugenuisance and waste of time.Instead, some of us have been thinking it Would Be Nice if we couldadjust the behavior on a missing page ("broken link") slightly. Insteadof saying "Wiktionary does not have an entry for this word yet", in thecase where Wiktionary does have an alternate-case version of the word,perhaps it should display an explicit "Did you mean?" link right upfront (along with but ahead of the other search and create options).There are probably several ways of approaching this. I've alreadyimplemented one way, but I'm curious as to this list's opinion of themost appropriate approach. 1. I added some code (in a test wiki) to getContent() in Article.php to optionally display "Did you mean ___?" before displaying 'noarticletext', in the case where an alternate-case version does exist. In some ways this is the right approach, but it's awkward, because it has to prepend its text to the 'noarticletext' boilerplate. Someone editing MediaWiki:noarticletext would reasonably expect to see the "Did you mean?" text there, and might want to integrate it with the rest of the boilerplate, but wouldn't be able to. 2. It might also be possible to implement the test and optional text right there in 'noarticletext', using the new in-line conditional expressions. (But I'm not sure they're quite powerful enough.) 3. Arguably, this is a problem that doesn't need solving, and the typical, already-existing "You can search for this article in Wiktionary" link should suffice. 4. Arguably, this is a problem that does need solving, but in an even more general case, whenever there are other kinds of near matches, that aren't appropriate to handle with redirects or with the automatic case mapping that happens when $wgCapitalLinks is on.(Someone might ask, "Why provide an interactive question and a link;why not just quietly redirect?" But that defeats the purpose of beingcaseful and makes it difficult or impossible to create a second entrywith the other case. If you're going to redirect in this case, youmight as well turn on $wgCapitalLinks and be done with it.)Another way of thinking of this is that the proposed "Did you mean?"question is a little like a disambiguation page, in a case where userconfirmation is required (i.e. in cases where a more implicit Wikiredirect or 302 redirect is not appropriate).For all I know this issue has been discussed already and some consensusreached. But does anyone have any advice or suggestions? Thanks.
10 16
0 0
Case inconsistency
by Steve Bennett 04 Jun '06

04 Jun '06
Hi all, Others must have noticed this - is this a recognised issue?Basically: Given some article whose title is in title case (eg, LyonMetro), you can type the lower case version in the go/search box, andstill get there. However, if you link to [[lyon metro]] in an article,it will show up as a red link.This has the effect that it's actually difficult to create the article*other* than going through the redlink - if you try and type in thename, you get silently redirected.Would it be wrong to be redirected towards the other cased versioninstead of having a redlink?Steve
6 14
0 0
Geo meta tags on wiki pages
by Neil Phillips 03 Jun '06

03 Jun '06
Hi,An increasing number of wiki pages use the {{Mapit-AUS-suburbscale|long=151.21459|lat=-33.87531}}Type notation to indicate the page relates to a specific location.Where would I go to request that this information is also embedded into ameta tag for the page e.g.<meta name="ICBM" content="-33.87531,151.21459" />So capable browsers/search engines can use this information moresemantically ?Cheers,Neil
9 16
0 0
autoloading classes
by Domas Mituzas 02 Jun '06

02 Jun '06
Hi,I have a small patch (2k lines) athttp://p.defau.lt/? Jnc0Y1AY0hc0SNOhmFtzSwthat eliminates most of require_once() calls and uses require() in __autoload() handler.Generally it makes things faster, as less require_once means less stat (), as well as that might be more APC-friendly.As well as some refactoring was needed, I could introduce lots of bugs.And break extensions of course.As included source is executed at function scope, rather than file scope, various other issues could arise - like missing global declarations, etc.So, please send your comments ;-)Domas
3 3
0 0
Results per page:

[8]ページ先頭

©2009-2025 Movatter.jp