Hello everyone.
I'm a sysop of Japanese Wikipedia. I'm going to delete many MediaWiki
namespace pages that have same contents as betawiki. I think this work
will make less operation cost.
I hava a question about caching and sever's overload. My colleague said
that local wiki's MediaWiki namescape pages may make less overload of
it's server, because these messages chaced and default messages are read
from files.
I think, default messages are in PHP code files and these PHP codes may
be compiled and cached between apache is alive. In other hand, messages
saved in local Wiki are in DB, and they are got from DB server by all
page requests.
Of course, even if local Wiki's MediaWiki namespace page don't exist,
access to DB server is needed - because we don't know which it exist or
not before access to DB server. Therefore non-existent of a MediaWiki
namespace page makes a addional process.
But does this "addional process" mean just continuation to execute
compiled codes without any reading from file or DB? This "overload" is
same as zero, I think.
It makes more overload to delete system massages in local wiki's
MediaWiki namespace pages?
Sorry for my poor English. Thank you.
----
[[w:ja:Mizusumashi]]
Say, e.g., api.php?action=query&list=logevents looks fine, but when I
look at the same table in an SQL dump, the Chinese utf8 is just a
latin1 jumble. How can I convert such strings back to utf8? I can't
find the place where MediaWiki converts them back and forth.
You see I'm just curious, let's say all I had was the SQL dump, and
GNU/Linux tools, but no MediaWiki. How can I get the original UTF-8
strings back out of the SQL dump?
Database error
>From Wikipedia, the free encyclopedia
Jump to: navigation, search
A database query syntax error has occurred. This may indicate a bug in
the software. The last attempted database query was:
(SQL query hidden)
from within function "ExternalStoreDB::store". MySQL returned error
"1114: The table 'blobs' is full (10.0.2.161)".
Thanks for the responses, all.
Daniel and Bilal: the notes about the possible servers at Syracuse and
Concordia are very interesting; it sounds like the researchers
interested in such things should team up.
Daniel: I am not sure what type of data is needed -- this is not my
project (I'm only the messenger!) but I'll pass along your message and
send you private details (and encourage the researcher to reply
himself).
River: Well, you say that part of the issue with the toolserver is
money and time... and this person that I've been talking to is
offering to throw money and time at the problem. So, what can they
constructively do?
All: Like I said, I am unclear on the technical issues involved, but
as for why a separate "research toolserver" might be useful... :
I see a difference in the type of information a researcher might want
to pull (public data, large sets of related page information,
full-text mining, ??) and the types of tools that the current
toolserver mainly supports (editcount tools, catscan, etc). I also see
a difference in how the two groups might be authenticated -- there's a
difference between being a trusted Wikipedian or trusted Wikimedia
developer and being a trusted technically-competent researcher (for
instance, I recognized the affiliation of the person who was trying to
apply, because I've read their research papers; but if you were going
on wikimedia status alone, they don't have any).
-- Phoebe
--
* I use this address for lists; send personal messages to phoebe.ayers
<at> gmail.com *
The meet-up[1] is drawing close now: between April 3. and 5. we meet at the
c-base[2] in Berlin to discuss MediaWiki development, extensions, toolserver
projects, wiki research, etc. Registration[3] is open until March 20 (required
even if you already pre-registered).
The schedule[4] is slowly becomming clear now: On Friday, we'll start at noon
with a who-is-who-and-does-what session and in the evening there will be an
opportunity to get to know Berlin a bit. On Saturday we have all day for
presentations and discussions, and in the evening we will have a party together
with all the folks from the chapter and board meetings. On Sunday there will be
a wrap-up session and a big lunch for everyone.
We have also organized affordable accommodation: we have reserved rooms in the
Apartmenthaus am Potsdamer Platz[5]. Staying there is a recommended way of
getting to know your fellow Wikimedians!
I'm happy that so many of you have shown interest, and I'm sure we'll have a
great time in Berlin!
Regards,
Daniel
[1] http://www.mediawiki.org/wiki/Project:Developer_meet-up_2009
[2] http://en.wikipedia.org/wiki/C-base
[3] http://www.mediawiki.org/wiki/Project:Developer_meet-up_2009/Registration
[4] http://www.mediawiki.org/wiki/Project:Developer_meet-up_2009#Outline
[5]
http://www.mediawiki.org/wiki/Project:Developer_meet-up_2009#Apartmenthaus_…
I understand this might be old.
Would it be at all possible to implement sizing an image to the
percentage of its containing element (table, div)? Or would such a
functionality be impossible "by design"?
Alternatively, please point me to the code fragments which produce the
Image: tags' markup for rendering in browsers.
Thanks.
Quick update on dump status:
* Dumps are back up and running on srv31, the old dump batch host.
Please note that unlike the wikis sites themselves, dump activity is
*not* considered time-critical -- there is no emergency requirement to
get them running as soon as possible.
Getting dumps running again after a few days is nearly as good as
getting them running again immediately. Yes, it sucks when it takes
longer than we'd like. No, it's not the end of the world.
* Dump runner redesign is in progress.
I've chatted a bit with Tim in the past on rearranging the architecture
of the dump system to allow for horizontal scaling, which will make the
big history dumps much much faster by distributing the work across
multiple CPUs or hosts where it's currently limited to a single thread
per wiki.
We seem to be in agreement on the basic arch, and Tomasz is now in
charge of making this happen; he'll be poking at infrastructure for this
over the next few days -- using his past experience with distributed
index build systems at Amazon to guide his research -- and will report
to y'all later this week with some more concrete details.
* Dump format changes are in progress.
Robert Rohde's p.o.c code for diff-based dumps is in our SVN and
available for testing.
We'll be looking at what the possibility on integrating this is to see
what the effect on dump performance is; currently performance and
reliability are our primary concerns, rather than output file size, but
they can intersect since the bzip2 data compression is a time factor.
This will be pushed back to later if we don't see an immediate
generation-speed improvement, but it's very much a desired project since
it will make the full-history dump files much smaller.
-- brion
Hi,
I am not sure if this is the correct place to ask this – if not then please let me know which is the best place for such a question.
Does anyone have experience importing the Wikipedia XML Dumps into MediaWiki. I made an attempt with the English Wiki Dump as well as the Portuguese Wiki Dump, giving php (cli) 1024 MB of Memory in the php.ini file. Both of these attempts fail with out of memory errors.
I am using the lasted version of MediaWiki 1.14.0 and PHP 5.2.6-1+lenny2 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 26 2009 22:41:04).
Does anyone have experience with this import and how to avoid the memory errors? I can give it more memory – but it seems to be leaking memory over time.
Thanks again,
O. O.
¡Sé el Bello 51 de People en Español! ¡Es tu oportunidad de Brillar! Sube tus fotos ya. http://www.51bello.com/
--- El dom, 8/3/09, O. O. <olson_ot(a)yahoo.com> escribió:
> I thought that the
> pages-articles.xml.bz2 (i.e. the XML Dump) contains
> the templates – but I did not find a way to do install it
> separately.
>
No, it only contains a dump of the current version of each article (involving the page, revision and text tables in the DB).
>
> Another thing I noticed (with the Portuguese Wiki which is
> a much
> smaller dump than the English Wiki) is that the number of
> pages imported
> by importDump.php and MWDumper differ i.e. importDump.php
> had much more
> pages than MWDumper. That is way I would have preferred to
> do this using
> importDump.php.
>
On download.wikimedia.org/your_lang_here you can check how many pages were supposed to be included in each dump.
You also have other parsers you may want to check (in my experience, my parser was slightly faster than mwdumper):
http://meta.wikimedia.org/wiki/WikiXRay_Python_parser
>
> Also in a previous post, you mentioned about taking care
> about the
> “secondary link tables”. How do I do that? Does
> “secondary links” refer
> to language links, external links, template links, image
> links, category
> links, page links or something else?
>
On the same page for downloads you have a list of additional dumps in SQL format (then compressed with gzip). I guess you may also want to import them (but of course, you don't need a parser for them, they can be directly loaded in the DB).
Best,
F.
> Thanks for your patience
>
> O.O.
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>